From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, gsv371(at)ukr(dot)net, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13941: Different value "pg_constraint.consrc" for similar Check Constrait |
Date: | 2016-02-10 17:46:05 |
Message-ID: | 29611.1455126365@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wed, Feb 10, 2016 at 9:47 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Why do you consider that a bug?
> Probably because of this 9.5 release note item:
> Adjust operator precedence to match the SQL standard (Tom Lane)
No, I think the difference is actually because of 2146f1340 (Avoid
recursion when processing simple lists of AND'ed or OR'ed clauses).
Before 9.5 you got nested BoolExprs out of either the BETWEEN ... AND
or the AND ... AND formulations. As of 2146f1340, the grammar produces a
single 3-argument BoolExpr for AND ... AND. I'm not sure offhand whether
it also produced that for BETWEEN ... AND at the time, but in any case it
would not have done so after 34af082f9 (Represent BETWEEN as a special
node type in raw parse trees).
Whether you have nested BoolExprs or a pre-flattened one has exactly zero
impact on semantics or execution behavior, since the planner will flatten
the nested case anyway; but you can tell the difference in ruleutils.c
output by counting the parens.
So the BETWEEN case hasn't changed, the AND ... AND case has, and I
entirely concur with Andres that this is not a bug.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-02-10 18:01:38 | Re: BUG #13935: Duplicate row in pg_constraint table which is not accessible via indexes |
Previous Message | David G. Johnston | 2016-02-10 17:01:00 | Re: BUG #13941: Different value "pg_constraint.consrc" for similar Check Constrait |