Re: LOCK for non-tables

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 21:06:29
Message-ID: m2mxn0a78q.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

I don't see anything better than documenting it using 2 extra lines:

LOCK [ TABLE ] [ ONLY ] name [, ...] [ IN lockmode MODE ]
LOCK TABLE tablename [ IN lockmode MODE ] [ NOWAIT ]
LOCK [ TABLE ] [ ONLY ] tablename IN lockmode MODE [ NOWAIT ]

Ok it looks like a mess, but that's what it is :)

And every user with "LOCK tablename NOWAIT" in their code would have to
change that to "LOCK TABLE tablename NOWAIT". Is there no way to reduce
that to only be a problem with tables named the same as the new objects
we want to add support for?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-01-16 21:07:13 Re: texteq/byteaeq: avoid detoast [REVIEW]
Previous Message Josh Berkus 2011-01-16 20:57:23 Re: pg_stat_replication security