On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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.
Hmm, OK.
> 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.
That strikes me as pretty unintuitive. I'd rather take the hit of
forcing people to write "LOCK TABLE foo" instead of just "LOCK foo"
than try to explain why they have to include "IN ACCESS EXCLUSIVE
MODE" if they want to stick "NOWAIT" on the end. However, I guess
it's a matter of opinion so... anyone else have an opinion?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company