On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.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?
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.
It does risk that. Same deal with making "=" have the same precedence as "<"
instead of keeping it slightly lower.
