Gábor E. Gévay

#17796 takes a big step towards eliminating the confusing error semantics of our logical operators, but there are some follow-up todos there: https://github.com/MaterializeInc/materialize/pull/17796#issuecomment-1441881016

More instances of this, frustrating nightly runs of SQLancer: https://github.com/MaterializeInc/materialize/issues/18346 Philip has some suggestions there for addressing some specific instances of the problem.

Some earlier discussions (collected by Philip): - https://github.com/MaterializeInc/materialize/issues/5670 - https://github.com/MaterializeInc/materialize/issues/4969 - https://github.com/MaterializeInc/materialize/issues/2418 - https://github.com/MaterializeInc/materialize/issues/9284

!! https://materializeinc.slack.com/archives/C02PPB50ZHS/p1683899532068649 Came from https://github.com/MaterializeInc/materialize/issues/19179, but it's a more general problem.

For the issue in the previous comment: We have a couple of checks in `PredicatePushdown` to not push literal errors past certain operators. (And I will now add one more...

Btw. basically all uses of `extract_non_errors_from_expr`, `extract_non_errors_from_expr_ref_mut`, and `extract_non_errors_from_expr_mut` are also sus of the above issue of specially handling only literal errors where the same special handling might be required...

One more tricky case: https://github.com/MaterializeInc/materialize/issues/19662 `count` manages to get lazy and swallow an error.

> As part of evaluating an MFP's filters to determine whether it will filter out an entire set of rows, we use AND to combine the results of multiple filters....

I've incorporated everything from the above comments into the issue description or into other issues that are linked from the issue description.

Thanks, added it to the "Null propagation vs. error propagation" category.