Andrew Dunstan <andrew@dunslane.net> writes:
> On 05/04/2011 07:39 PM, Tom Lane wrote:
>> If you try the experiment, you find out that the first interpretation is
>> preferred by the current grammar:
>> ERROR: operator does not exist: integer %% unknown
> Yeah, IIRC the default action for a shift/reduce conflict is to shift,
> as it's usually the right thing to do.
Well, there's nothing "default" about it: we've got precedence
declarations that specifically tell it to do that. I'm just disturbed
because this isn't what those precedences were meant to do.
>> I would be happier if we could also not mark NULL, because that's surely
>> used in a lot of other places, and could easily bite us a lot harder
>> than this. Can anyone think of an alternative way to resolve this
>> particular conflict without the blunt instrument of a precedence marking?
> My bison-fu is a bit rusty, but years ago I could do this stuff in my
> sleep. I'll be surprised if there isn't a way.
> 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.)
But it would still make life safer for future grammar hacking if it
didn't have precedence at all.
BTW, I wonder why NOTNULL and ISNULL have their own precedence levels,
rather than being made to act exactly like IS [NOT] NULL ...
regards, tom lane