Re: LOCK for non-tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, fgp(at)phlo(dot)org, simon(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: LOCK for non-tables
Date: 2011-01-14 18:58:40
Message-ID: 9253.1295031520@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-01-14 19:01:14 Re: limiting hint bit I/O
Previous Message Kevin Grittner 2011-01-14 18:52:39 Re: limiting hint bit I/O