I wrote:
> It looks to me like the reason why there's a shift/reduce conflict is
> not so much that TABLE is optional as that we allow the syntax
> LOCK tablename NOWAIT
BTW, I did confirm this to the extent of showing that the shift-reduce
conflict could be eliminated by attaching precedences to SEQUENCE and
NOWAIT, a la
%nonassoc NOWAIT
%nonassoc SEQUENCE
This causes the ambiguous case
LOCK SEQUENCE NOWAIT
to be resolved by reducing SEQUENCE to unreserved_keyword, ie it's a
NOWAIT request for a table named "sequence", which is backwards
compatible. However, I'm not seriously proposing this as a usable fix.
I think there's far too much risk of unforeseen side-effects on the
behavor of other productions. We'd have to similarly attach a
precedence to every object-type keyword that we cared to use in LOCK,
and that would mean the potential for bollixing the behavior of an awful
lot of cases.
I think the realistic options are (1) change the syntax
non-backward-compatibly or (2) don't add any functionality here.
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
