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

From Tom Lane
Subject Re: Precedence of standard comparison operators
Date
Msg-id 22935.1424450659@sss.pgh.pa.us
Whole thread Raw
In response to Re: Precedence of standard comparison operators  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: Precedence of standard comparison operators
List pgsql-hackers
Kevin Grittner <kgrittn@ymail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> the precedence of <= >= and <> is neither sane nor standards compliant.

> I wonder whether it would be feasible to have an option to generate
> warnings (or maybe just LOG level messages?) for queries where the
> results could differ.

My guess (admittedly not yet based on much) is that warnings won't be too
necessary.  If a construction is parsed differently than before, you'll
get no-such-operator gripes.  The case of interest is something like
a <= b %% c

which was formerly
(a <= b) %% c

and would become
a <= (b %% c)

Now, if it worked before, %% must expect a boolean left input; but the
odds are pretty good that b is not boolean.

This argument does get a lot weaker when you consider operators that
take nearly anything, such as ||; for instance if a b c are all text
then both parsings of
a <= b || c

are type-wise acceptable.  But that's something that I hope most people
would've parenthesized to begin with, because (a <= b) || c is not exactly
the intuitive expectation for what you'll get.

Anyway, to answer your question, I think that Bison knows somewhere inside
when it's making a precedence-driven choice like this, but I don't believe
it's exposed in any way that we could get at easily.  Perhaps there would
be a way to produce a warning if we hand-hacked the C-code bison output,
but we're not gonna do that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Precedence of standard comparison operators
Next
From: Kevin Grittner
Date:
Subject: Re: Precedence of standard comparison operators