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
