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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers