Re: BUG #3822: Nonstandard precedence for comparison operators

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> That said, bringing PostgreSQL into compliance with the standard
> would undoubtedly break some people's existing applications.

The spec seems to barely have a notion of operator precedence at all ---
for example, all the variants of <predicate> are at the same precedence
level, and if I'm reading it right they actively disallow ambiguous
cases by requiring parentheses; note the way that <boolean primary>
is defined. This entire arrangement breaks down as soon as you consider
user-defined operators that yield boolean results. So I'm not
particularly excited about the idea of slavish compliance with the spec
in this area.

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.

> 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.

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.

regards, tom lane