Greg Stark <st...@mit.edu> wrote: > On Wed, Mar 11, 2015 at 8:00 PM, Kevin Grittner <kgri...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
