Michael Paquier <michael.paquier@gmail.com> writes:
> On Tue, Sep 9, 2014 at 10:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The reason for the assert is that there should never be an OR directly
>> underneath an OR in the planner after eval_const_expressions has flattened
>> such cases. Evidently commit f343a88 failed to preserve AND/OR flatness
>> in some cases :-(. That code should be taught to do so, rather than
>> lobotomizing this assertion. Lack of flatness causes optimization
>> inefficiencies, which is why we don't want to just allow it.
> Ah, OK, I just saw your commit. so the trick is to add the arguments
> of subclause in case of an OR clause found to have a correct
> flattening here... Thanks!
Right. If you look again at that code in orclauses.c, you'll notice that
it is itself assuming AND/OR flatness in its input. We could discard
that assumption, but it would just mean moving complexity from the places
that currently have to preserve flatness to other places. For instance,
right now we suppose that all "top level" WHERE clauses are in the
top-level AND list ... if we had to check for sub-AND clauses and recurse
into those, it would make life complicated in numerous places.
I do wonder, having seen this bug, if there's someplace we could add
assertions to check for AND/OR flatness that'd be more certainly hit
by a violation.
regards, tom lane