I wrote:
> Andrew Dunstan <and...@dunslane.net> writes:
>> If we do need a precedence setting for NULL_P, then I think it should
>> probably be on its own and not sharing one with IS.
> Yeah, I was thinking that too. If we put %prec on the IS [NOT] NULL
> productions then there is no need for NULL_P to have exactly its current
> precedence; anything above POSTFIXOP would preserve the current behavior
> in the DEFAULT ... NULL case. (And if we decided we wanted to flip that
> behavior, anything below POSTFIXOP would do that.)
On reflection I decided that the best quick-fix is to put NULL into the
list of keywords that are already precedence-grouped with IDENT. That
at least makes sure that it has precedence behavior equivalent to any
plain old non-keyword. If you can find a better fix, maybe we could
apply it to the other cases mentioned there as well.
> BTW, I wonder why NOTNULL and ISNULL have their own precedence levels,
> rather than being made to act exactly like IS [NOT] NULL ...
Is anybody up for changing that, or should we leave well enough alone?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
