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

On Wed, Feb 26, 2014 at 10:21:03PM -0500, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > On Tue, Feb 25, 2014 at 01:15:09PM -0500, Tom Lane wrote:
> >> Really if we wanted to fix
> >> this issue we'd need to hack up transformAExprAnd/transformAExprOr so that
> >> they recognized nested ANDs/ORs and flattened them on the spot. This
> >> might not be a bad idea, but it's starting to look like more than a quick
> >> hack patch.
>
> > Reminds me of this work:
> > http://www.postgresql.org/message-id/flat/CABwTF4XJKN1smMjHv_O-QzTpokqSjHBouMWVw-E8kyb2bC=_wg(at)mail(dot)gmail(dot)com
> > http://www.postgresql.org/message-id/flat/CAFj8pRDd9QTyoY0cbPoODR-hfj1xaMBuxWOxAZg0kyVtVaunkw(at)mail(dot)gmail(dot)com
>
> 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?

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

+ Everyone has their own god. +