Re: BUG #3822: Nonstandard precedence for comparison operators

Michael Glaesemann <grzm(at)seespotcode(dot)net> writes:
> I'm probably being dense, but I don't see how this is an issue.

That's just a bug in his example ;-)

The real question is whether there is enough of a problem here to
justify creating new problems, in the form of backwards-compatibility
hazards. One complaint in ten years tells me there's not. We know
what the SQL-portability hot-button issues are, because we have gotten
repeated complaints about them --- identifier case-folding and
backslashes in string literals are two that spring to mind instantly.
If operator precedence were an issue worth spending time on, it would
have come up before, repeatedly.

I would not actually object to making small tweaks in the precedence
rules to move a little closer to spec compliance; it undoubtedly is
just plain weird that = and <> have their own precedence rules.
However, "closer to spec" is a lot weaker argument than "matches spec",
and I really don't think that we want to try to match the spec exactly
in this area.

What I do *not* want to do is invest the level of effort suggested
by Kevin, with two grammars or whatever it would take to make that
happen. This problem is not worth that.

regards, tom lane