Re: Precedence of standard comparison operators

Here's a completed patch for this. This includes fixing the NOT LIKE
problem as discussed in the other thread.

I've done more-or-less-exhaustive testing on this to verify that it
produces warnings whenever necessary. It generates a few false-positive
warnings in corner cases that seem too complicated to model more precisely.
An example is that the production for "= ANY (sub-select)" clauses looks
like

a_expr subquery_Op sub_type select_with_parens %prec Op

but in point of fact its precedence against operators to its left is
not necessarily Op, but whatever actual operator appears --- for
example "= ANY" has the precedence of "=". This is because of the same
point noted in the other thread that Bison really implements that by
comparison to the lookahead token's precedence, not the rule's declared
precedence. The patch treats this as having precedence Op, which is
the highest possibility, so it will sometimes warn unnecessarily.

regards, tom lane