On Wed, Feb 26, 2014 at 10:21:03PM -0500, Tom Lane wrote: > Noah Misch <n...@leadboat.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=_...@mail.gmail.com > > http://www.postgresql.org/message-id/flat/cafj8prdd9qtyoy0cbpoodr-hfj1xambuxwoxazg0kyvtvau...@mail.gmail.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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers