Re: LOCK for non-tables

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