On Thu, Feb 27, 2014 at 8:51 AM, Tom Lane <t...@sss.pgh.pa.us> 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. > ruleutils should be fine. See code below in ruleutils.c 6615 case AND_EXPR: 6616 if (!PRETTY_PAREN(context)) 6617 appendStringInfoChar(buf, '('); 6618 get_rule_expr_paren(first_arg, context, 6619 false, node); 6620 while (arg) 6621 { 6622 appendStringInfoString(buf, " AND "); 6623 get_rule_expr_paren((Node *) lfirst(arg), context, 6624 false, node); 6625 arg = lnext(arg); 6626 } 6627 if (!PRETTY_PAREN(context)) 6628 appendStringInfoChar(buf, ')'); 6629 break; Similar code exists for OR_EXPR. Within the planner, I have seen the quals are always implicitly ANDed lists, where all ANDs are put into a single list. May be same with OR. As a side note, the code blocks for AND_EXPR and OR_EXPR are almost same except words "AND" and "OR". So there is some chance to get rid of some code duplication here. > > 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 > -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
