"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wed, Feb 10, 2016 at 9:47 AM, Andres Freund <andres@anarazel.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
