Re: Precedence of standard comparison operators

Peter Eisentraut <peter_e@gmx.net> writes:
> We could check if there is a >= or <= as a child of another general
> operator.  That is already quite unlikely to begin with (except for the
> obvious common case I am forgetting right now).  We could even do this
> in an external module with a hook.  Or to be more precise, check whether
> the >= or <= was in parentheses, which we could record in the parser.
> Neither might be absolutely accurate, but it would at least give users a
> list of things to check.

> The above would imply that we add these checks before changing the
> precedence.  Creating a check under the new precendence would be much
> harder.

Hm.  Well, assuming that we're satisfied with just having a way to warn
when the behavior changed (and not, in particular, a switch that can
select old or new behavior), I think it might not be that hard.  The point
is that we're going to reduce the precedence of <= and friends, which
means that some other operator that might formerly have bound less tightly
might now bind more tightly and thereby be underneath the <= instead of
above it.  So it seems like we could adapt your idea: in transformAExprOp,
if the opname is <= etc, then check to see if the righthand argument is
another A_Expr with a multicharacter Op name.  If so warn.  As you said,
we'd need to mark parenthesized subexpressions but that might not be
horridly painful.
        regards, tom lane