Greg Stark <stark@mit.edu> wrote:
> On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
>> If there are no false positives, turning it on is zero impact
>> (except for any performance impact involved in detecting the
>> condition) for those who have no problems.
> Think of this as a bug fix.
I do. :-)
> Hopefully nobody was using the syntax before because it didn't
> work right and if it did they were depending on the broken
> behaviour.
Right; and they may have millions of lines of code which have been
carefully tested and in production for years, and which may
suddenly start to generate incorrect results on queries *or mangle
existing data* with the fix unless they change their SQL code.
> But once it's fixed it would be frustrating to have it be fixed
> but have a warning saying "WARNING this query works fine now but
> didn't work in previous versions".
That's getting into subjective territory. What you say "works
fine" may be completely unintended an unexpected, and may cause
serious disruption of their business. You seem to be arguing that
they deserve it for counting on our old, buggy implementation, and
coming to accept that as expected behavior.
> Especially since warnings in DML are effectively fatal errors due
> to the frequency that they'll fire.
In what situation? Code which was running under a previous major
release of PostgreSQL? If they are getting so many of these
warnings in that case, they would probably prefer to have this
caught in pre-upgrade testing or at least as soon as possible. If
it is new code written under 9.5 one would hope they have a testing
phase where this would be detected so they could choose to add the
parentheses needed to maintain portable code or turn off the
warning.
> The warning can be useful for people testing code written in old
> versions or writing code intended to be multi-version compatible.
We agree there...
> But it's not something someone would want if they're writing code
> for 9.5.
... and we also agree here; but I'm saying that in that case it
will still rarely come up and if it does it's easy enough to
disable. That inconvenience is not sufficient to not want to, by
default, mangle the data or query results of some small percentage
of existing users.
If we ship with this off the results are entirely predictable. It
will be somewhat surprising not to see any negative headlines about
it.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company