Обсуждение: [GENERAL] 9.5 "chained equality" behavior
Our team is upgrading from 9.4 to 9.5, and we noticed this behavior change:
--
9.4:
# SELECT true = true = true;
?column?
----------
t
(1 row)
9.5:
# SELECT true = true = true;
ERROR: syntax error at or near "="
LINE 1: SELECT true = true = true;
Now, there's actually a larger problem with this, since it's not actually chained equality and only looks like it. It looks like 9.4 is evaluating right-to-left. We're going to fix usages of this to instead do (a = b && a = c) instead of (a = b = c).
However, I wanted to email in because I couldn't see what in the 9.5 changelog (https://www.postgresql.org/docs/9.6/static/release-9-5.html) would cause this to syntax error. I'm worried that there are other incompatibilities that we didn't notice.
Can anyone shed some light?
Joshua Ma
Benchling | benchling.com
Joshua Ma schrieb am 30.05.2017 um 22:56: > We're going to fix usages of this to > instead do (a = b && a = c) instead of (a = b = c). That has to be (a = b AND a = c) The && operator is not valid for booleans
Joshua Ma <josh@benchling.com> writes: > Our team is upgrading from 9.4 to 9.5, and we noticed this behavior change: > 9.5: > # SELECT true = true = true; > ERROR: syntax error at or near "=" > LINE 1: SELECT true = true = true; > Now, there's actually a larger problem with this, since it's not actually > chained equality and only looks like it. It looks like 9.4 is evaluating > right-to-left. We're going to fix usages of this to instead do (a = b && a > = c) instead of (a = b = c). > However, I wanted to email in because I couldn't see what in the 9.5 > changelog (https://www.postgresql.org/docs/9.6/static/release-9-5.html) > would cause this to syntax error. This is a consequence of commit c6b3c939b "Make operator precedence follow the SQL standard more closely", which removed the former "%right '='" grammar declaration. That caused "a = b = c" to be parsed as "a = (b = c)", which was surprising, and wouldn't work at all unless a was boolean. Now "=" is declared %nonassoc, so that if you actually want behavior like that, you need to write some parens. But it seems much more likely that people writing that are making a mistake. We discussed the associativity-of-= issue in the thread leading up to that patch, https://www.postgresql.org/message-id/flat/12603.1424360914%40sss.pgh.pa.us but I evidently forgot to mention this detail in the commit log message, so it didn't get into the release notes either. regards, tom lane
Our team is upgrading from 9.4 to 9.5, and we noticed this behavior change:9.4:# SELECT true = true = true;?column?----------t(1 row)9.5:# SELECT true = true = true;ERROR: syntax error at or near "="LINE 1: SELECT true = true = true;Now, there's actually a larger problem with this, since it's not actually chained equality and only looks like it.
I'm not understanding what the larger problem is here.
It looks like 9.4 is evaluating right-to-left.
Its documented as such.
We're going to fix usages of this to instead do (a = b && a = c) instead of (a = b = c).
As noted by Thomas, AND, not &&
However, I wanted to email in because I couldn't see what in the 9.5 changelog (https://www.postgresql.org/docs/9.6/static/release-9-5. html) would cause this to syntax error. I'm worried that there are other incompatibilities that we didn't notice.
The first bullet item could be construed to cover this particular behavior change:
* Adjust operator precedence to match the SQL standard (Tom Lane)
The commit behind that release note doesn't mention this particular behavior change explicitly though.
The documentation change was done correctly. Prior to 9.5 "=" was its own group and had right associativity just as you observe. In 9.5 it moved to the comparison operators section which don't have associativity - namely because aside from equality all of the comparison operators convert their inputs to a boolean and so cannot be placed in sequence like shown here (boolean compared to, say, integer doesn't work). Boolean equality is the one exception which is what no longer works - so the docs are correct.
I suspect the answer is that the current behavior is intentional and has some support in either consistency or the SQL standard.
David J.
...namely because aside from equality all of the comparison operators convert their inputs to a boolean and so cannot be placed in sequence like shown here (boolean compared to, say, integer doesn't work). Boolean equality is the one exception which is what no longer works - so the docs are correct.
Yes, that was poorly written...booleans keep the same type and so can be "chained" while other types do not. But precedence is not based upon type, just the operator.
David J.
> On 30 May 2017, at 22:56, Joshua Ma <josh@benchling.com> wrote: > > Our team is upgrading from 9.4 to 9.5, and we noticed this behavior change: > > 9.4: > # SELECT true = true = true; > ?column? > ---------- > t > (1 row) Does that really do what you intended though? # select false = false = false; ?column? ---------- f (1 row) I suspect you expect that to result in 't', not 'f', so replacing that with AND would change the behaviour for false booleanvalues. (This is from 9.3, btw) Perhaps explicitly adding the braces that pre-9.5 pg adds implicitly gets you what you had? I suspect that would work on9.5 as well (but can't test right now). # select false = (false = false); ?column? ---------- f (1 row) # select true = (true = true); ?column? ---------- t (1 row) Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest.