Bradley Baetz <bbaetz@acm.org> writes:
> Or are we guaranteed that there wont' be OR/AND expressions
> inside a NOT, because they will have always been expanded?
No, we're not, because the CNF-ifying code is optional. If you study
the heuristics in prepqual.c you could doubtless devise a query that has
such an expression somewhere in it.
Even if that was a safe assumption today, writing code that would fail
in as subtle a way as this when presented with such a tree won't do.
The optimizer gets revamped constantly, and so I don't want to see any
assumptions that fragile embedded into pieces of it.
> Do we agree that if the thing inside the NOT is a single expression,
> then what I've doing is safe? IS it safe even if theres and/or involved
> as the argument to a (strict) operator?
I'm going to take the position "fix it right or don't touch it at all".
The routine as it stands does what it was intended to do. If you want
to invest the effort to take it to the next level of intelligence, great
--- but let's not put in a half-baked attempt.
regards, tom lane
