Re: Precedence of standard comparison operators

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Sun, Aug 09, 2015 at 04:48:22PM -0400, Tom Lane wrote:
>> I'm curious about your rationale for claiming that <null predicate> has
>> precedence exactly equal to "<" according to the spec.

> Both <null predicate> and <comparison predicate> are in the set of productions
> that take <row value predicand> arguments and appear only in <predicate>.
> Passing a production in that set as an argument to a production in that set
> requires parentheses. To restate (non-associative) "precedence equal" more
> pedantically, there exists no conforming query whose interpretation hinges on
> the relative precedence of "IS NULL" and "<".

Ah. So really, according to the spec IS and "<" could have any precedence
relative to each other as long as there is no other construct between.
Works for me.

> To my knowledge, SQL is agnostic about whether LIKE "is an operator". The six
> comparison operators bind looser than <common value expression> syntax like
> "*" and "||", tighter than IS TRUE, and indistinguishable from <predicate>
> syntax like IS DISTINCT FROM and LIKE.

"Indistinguishable" in the same sense as above, right? So for our
purposes, it's better to keep BETWEEN and friends as binding slightly
tighter than '<' than to make them the same precedence. Same precedence
risks breaking things that weren't broken before. Also, while I argued
above that making BETWEEN a potential argument for LIKE wasn't sensible,
that's not true for the comparison operators. In particular, boolean '<='
is the only SQL-provided spelling for logical implication.

>> OVERLAPS is a special case in that it doesn't really need precedence at
>> all: both its arguments are required to be parenthesized. We could
>> possibly have removed it from the precedence hierarchy altogether, but
>> I didn't bother experimenting with that, just left it alone. But
>> because of that, "moving BETWEEN/IN below it" doesn't really change
>> anything.

> Ah, quite right. SQL OVERLAPS takes various forms of two-column input, but
> PostgreSQL OVERLAPS is more particular. I like your subsequent proposal to
> remove OVERLAPS from the order of precedence.

Yeah. If we ever extend our OVERLAPS syntax, we might have to assign a
precedence to OVERLAPS, but we can do that then --- and it would be good
if we did not at that time have a false impression that the precedence
was already determined by previous decisions. I'll go make that change.

regards, tom lane