| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: LOCK for non-tables |
| Date: | 2011-01-16 17:28:42 |
| Message-ID: | 9237.1295198922@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:
> Do we wish to officially document LOCK without TABLE as a good idea to
> start avoiding, in case we decide to do something about that in the
> future?
I'm still not for fixing the ambiguity that way. TABLE is an optional
noise word in other contexts, notably GRANT/REVOKE where that syntax is
dictated by SQL standard. It would be inconsistent to have it be
required in LOCK.
I think we should deprecate using NOWAIT without an IN...MODE clause.
Another possibility is to disallow just the single case
LOCK tablename NOWAIT
ie, you can write NOWAIT if you include *either* the object type
or the IN...MODE clause. This is not too hard as far as the grammar
is concerned, but I'm not exactly sure how to document it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-01-16 17:32:30 | Re: auto-sizing wal_buffers |
| Previous Message | Magnus Hagander | 2011-01-16 17:20:55 | Re: pg_basebackup for streaming base backups |