Re: BUG #13941: Different value "pg_constraint.consrc" for similar Check Constrait
От | Tom Lane |
---|---|
Тема | Re: BUG #13941: Different value "pg_constraint.consrc" for similar Check Constrait |
Дата | |
Msg-id | 29611.1455126365@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #13941: Different value "pg_constraint.consrc" for similar Check Constrait ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: