Re: Precedence of standard comparison operators - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Precedence of standard comparison operators
Date
Msg-id CA+TgmoY6mi-sf8UK7-T-JTUmGEH9vn2dNfK9VscQTeD=DoofSw@mail.gmail.com
Whole thread Raw
In response to Re: Precedence of standard comparison operators  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Precedence of standard comparison operators  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
>> <david.g.johnston@gmail.com> wrote:
>>> I would vote for Auto meaning On in the .0 release.
>
>> I don't think users will appreciate an auto value whose meaning might
>> change at some point, and I doubt we've have much luck identifying the
>> correct point, either.  Users will upgrade over the course of years,
>> not months, and will not necessarily complete their application
>> retesting within any particular period of time thereafter.
>
> Yeah, I think that's too cute by far.  And people do not like things like
> this changing in point releases.  If we do this, I envision it as being
> on by default in 9.5 and then changing the default in 9.6 or 9.7 or so.
>
> Another possibility is to leave it on through beta testing with the intent
> to turn it off before 9.5 final; that would give us more data about
> whether there are real issues than we're likely to get otherwise.

To my mind, the fact that we're doing this at all is largely
predicated on the fact that there won't be many real issues.  So I
think the goal of the debugging messages ought to be to let those
people who discover that they do have issues track them down more
easily, not to warn people.  Warning is sort of closing the barn door
after the horse has got out: hey, by the way, I just broke your app.

Another thing to consider is that if it becomes common to run with
these warnings on, then everybody will have to pretty much write their
code with full parenthesization anyway, at least if they plan to
publish their code on PGXN or anywhere that it might get run on some
system other than the one it was written for.  That seems like an
annoying gotcha for an issue that we're not expecting to be common.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal: disallow operator "=>" and use it for named parameters
Next
From: Robert Haas
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()