Re: [GENERAL] 9.5 "chained equality" behavior - Mailing list pgsql-general

From David G. Johnston
Subject Re: [GENERAL] 9.5 "chained equality" behavior
Date
Msg-id CAKFQuwbKPbqn4SHVPRrVP8dwvn0aFKrouxTZa4yV6Hq+K9L4Yg@mail.gmail.com
Whole thread Raw
In response to [GENERAL] 9.5 "chained equality" behavior  (Joshua Ma <josh@benchling.com>)
Responses Re: [GENERAL] 9.5 "chained equality" behavior  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general
On Tue, May 30, 2017 at 1:56 PM, 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)

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.


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] 9.5 "chained equality" behavior
Next
From: "David G. Johnston"
Date:
Subject: Re: [GENERAL] 9.5 "chained equality" behavior