Re: Precedence of standard comparison operators

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Precedence of standard comparison operators
Date: 2015-03-10 16:11:57
Message-ID: 17174.1426003917@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On February 26, 2015 10:29:18 PM CET, Peter Eisentraut <peter_e(at)gmx(dot)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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-03-10 16:14:39 Re: proposal: disallow operator "=>" and use it for named parameters
Previous Message Petr Jelinek 2015-03-10 16:07:56 Re: proposal: disallow operator "=>" and use it for named parameters