tlp: investigate whether TLP with prepared statements can catch #71002

[mgartner]

Once #71323 is merged, TLP should be able to catch the bug described in #71002. We should test this assumption. If TLP fails to catch it, we should figure out why and address the issue.

@nehageorge attempted this already without success so far:

Tried it three times so far and no luck yet :( ... I think we may have to run it many many times since getBoolExprContext most often returns true, false, or NULL, and we can't add placeholders to those expressions.

Perhaps we need to change the random predicate generated so that it returns true, false, and NULL less often.

[nehageorge]

Looked into this. I was able to get TLP to reproduce the known issue locally. However, I had to make my own custom function that builds "compound" comparator expressions with placeholders. By compound comparator expressions, I mean conjunctions and disjunctions of expressions like "col1 = $1"

With the existing TLP implementation, like I hinted at earlier, the probability of creating a statement with multiple "datum" expressions is very slim, which is fine for non-prepared statements. However, this creates an issue for testing prepared statements as we end up having many statements that don't use placeholders at all.

My proposed solution is to redefine makeBoolExprWithPlaceholders to implement what I have implemented locally. This will ensure that many valid prepared statements with placeholders are being tested. Since makeBoolExpr ensures test coverage for statements that are not just comparator conjuncts and disjuncts, I don't think that this proposes a grave test coverage issue.

My focus might be skewed by knowing the specifics of where issue #71002 was seen. I'd love to hear others' thoughts on this, especially regarding the test coverage of my proposed approach. Do you think we need to be testing other types of prepared statements?

@mgartner

[nehageorge]

Talked to @mgartner async. Closing this issue for now as we've proved that we could have caught #71002 with TLP. However, a general issue with using sqlsmith infrastructure for TLP testing is the fact that makeBoolExpr so often generates true, false, and NULL as predicates. We should instead test more meaningful and less redundant predicates. See #71675.