On Sun, Aug 09, 2015 at 06:44:58PM -0400, Tom Lane wrote: > Noah Misch <n...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
