Robert Haas <robertmh...@gmail.com> writes:
> Tom - I am willing to implement this if you think it's valuable, but
> I'd like your input on the syntax.
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
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
If that weren't possible, then a table name would have to be followed by
EOL or IN (which is full-reserved), while an optional object type name
could not be followed by either, so there would be no shift/reduce
conflict. So we broke it when we added NOWAIT, not when TABLE was made
optional.
So it looks to me like there are at least two fixes other than the ones
you enumerated:
1. Make NOWAIT a reserved word. Not good, but perhaps better than
reserving all the different object type names.
2. Disallow the above abbreviated syntax; allow NOWAIT only after an
explicit IN ... MODE phrase. This would probably break a couple of
applications, but I bet a lot fewer than changing the longer-established
parts of the command syntax would break.
I think #2 might be the best choice 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
