Fix grammar's AND/OR flattening to work with operator_precedence_warning.

It'd be good for "(x AND y) AND z" to produce a three-child AND node
whether or not operator_precedence_warning is on, but that failed to
happen when it's on because makeAndExpr() didn't look through the added
AEXPR_PAREN node.  This has no effect on generated plans because prepqual.c
would flatten the AND nest anyway; but it does affect the number of parens
printed in ruleutils.c, for example.  I'd already fixed some similar
hazards in parse_expr.c in commit abb164655, but didn't think to search
gram.y for problems of this ilk.  Per gripe from Jean-Pierre Pelletier.

Report: <fa0535ec6d6428cfec40c7e8a6d11156@mail.gmail.com>
This commit is contained in:
Tom Lane 2016-06-03 19:12:30 -04:00
parent 8355897ff2
commit c82037e372
1 changed files with 16 additions and 4 deletions

View File

@ -14512,10 +14512,16 @@ doNegateFloat(Value *v)
static Node *
makeAndExpr(Node *lexpr, Node *rexpr, int location)
{
Node *lexp = lexpr;
/* Look through AEXPR_PAREN nodes so they don't affect flattening */
while (IsA(lexp, A_Expr) &&
((A_Expr *) lexp)->kind == AEXPR_PAREN)
lexp = ((A_Expr *) lexp)->lexpr;
/* Flatten "a AND b AND c ..." to a single BoolExpr on sight */
if (IsA(lexpr, BoolExpr))
if (IsA(lexp, BoolExpr))
{
BoolExpr *blexpr = (BoolExpr *) lexpr;
BoolExpr *blexpr = (BoolExpr *) lexp;
if (blexpr->boolop == AND_EXPR)
{
@ -14529,10 +14535,16 @@ makeAndExpr(Node *lexpr, Node *rexpr, int location)
static Node *
makeOrExpr(Node *lexpr, Node *rexpr, int location)
{
Node *lexp = lexpr;
/* Look through AEXPR_PAREN nodes so they don't affect flattening */
while (IsA(lexp, A_Expr) &&
((A_Expr *) lexp)->kind == AEXPR_PAREN)
lexp = ((A_Expr *) lexp)->lexpr;
/* Flatten "a OR b OR c ..." to a single BoolExpr on sight */
if (IsA(lexpr, BoolExpr))
if (IsA(lexp, BoolExpr))
{
BoolExpr *blexpr = (BoolExpr *) lexpr;
BoolExpr *blexpr = (BoolExpr *) lexp;
if (blexpr->boolop == OR_EXPR)
{