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

On Sat, Apr 19, 2014 at 05:50:17PM -0400, Tom Lane wrote:
> 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.

OK, thanks for the feedback.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +