Re: Avoiding deeply nested AND/OR trees in the parser

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Wed, Feb 26, 2014 at 10:21:03PM -0500, Tom Lane wrote:
>> Oh, I'd forgotten about that thread. I never particularly liked the patch
>> as presented: like Robert, I thought it far too complicated. My
>> inclination would just be to tweak the parser enough so that a simple list
>> of ANDs or ORs (ie, a left-deep raw parse tree) gets flattened.
>>
>> The most likely bet for making that happen in an uncomplicated way would
>> be to alter gram.y's processing: if we had the productions for AND/OR
>> notice whether their left inputs were already AND/OR clauses, they could
>> extend the argument lists instead of building nested clauses. The reason
>> the proposed patch is so complicated is it's trying to avoid recursing
>> while handling a fundamentally recursive data structure, and that's just
>> the hard way to do it.
>>
>> We do need to look at whether there are any implications for ruleutils
>> and other places, though.

> Where are we on this? Is it being kept for 9.5?

I think we rejected the patch-as-presented, and no one's bothered to
create a new one, which suggests that the problem isn't all that
important ...

I suspect the gram.y change I suggest above would be about a ten-line
patch. What makes it less than completely trivial is the need to chase
down all the downstream implications, such as whether ruleutils would
need any work, and whether anything else is expecting parser output
to contain only binary clauses.

regards, tom lane