Re: BUG #3822: Nonstandard precedence for comparison operators

>>> On Thu, Dec 27, 2007 at 4:22 PM, in message <21242(dot)1198794130(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:

> To the extent that you do believe the spec, there are more problems with
> our precedence rules than just where <= fits --- it looks to me like IS
> [NOT] NULL is at the wrong precedence, too. And then there's the whole
> question of associativity.

Well, surely, the fact that there is more than one problem isn't,
by itself, an argument not to fix any of them.

>> It seems to call for the same phased approach as the standard
>> conforming string literals, with GUCs to control warnings for problem
>> constructs and legacy versus standard runtime behavior.
>
> Good luck implementing that --- the precedence is hard-wired into the
> bison grammar rules. There are also extremely good reasons for not
> having GUC variables that affect parsing behavior.

But we have done so before, in the interests of converging on the
standard.

> Given that it's been this way for ten years and no one has complained
> before, I'm disinclined to change it, and even more disinclined to
> invest the effort that would be involved in letting the behavior vary
> at runtime.

That's a fair point. It's very unlikely to bite an existing
PostgreSQL user very hard. The pain could come in migrating a large
set of complex queries from another DBMS. I don't recall seeing any
migration document to help people identify these issues up front,
but we should probably have one (if we don't) and this should
probably be mentioned.

Based on this discussion, I'll remind our staff to be generous in
the use of parentheses when doing ad hoc queries.

-Kevin