On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Andres Freund <and...@anarazel.de> writes: >>> On February 26, 2015 10:29:18 PM CET, Peter Eisentraut <pete...@gmx.net> >>> wrote: >>>> My suggestion was to treat this like the standard_conforming_string >>>> change. That is, warn for many years before changing. > >>> I don't think scs is a good example to follow. > >> Yeah. For one thing, there wouldn't be any way to suppress the warning >> other than to parenthesize your code, which I would find problematic >> because it would penalize standard-conforming queries. I'd prefer an >> arrangement whereby once you fix your code to be standard-conforming, >> you're done. > >> A possible point of compromise would be to leave the warning turned on >> by default, at least until we get a better sense of how this would >> play out in the real world. I continue to suspect that we're making >> a mountain out of, if not a molehill, at least a hillock. I think most >> sane people would have parenthesized their queries to start with rather >> than go look up whether IS DISTINCT FROM binds tighter than <= ... > > This thread seems to have died off without any clear resolution. I'd > hoped somebody would try the patch on some nontrivial application to > see if it broke anything or caused any warnings, but it doesn't seem > like that is happening. > > Do we have consensus on doing this? Should we have the warning on > by default, or off?
I vote for defaulting the warning to off. If that proves to be too problematic, I'd take that as a sign that this whole change is not as low-impact as we're hoping, and maybe consider a rethink. -- Robert Haas EnterpriseDB: 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
