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 19:48:08
Message-ID: 10015.1295034488@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:
> On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

> 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?

It doesn't seem amazingly unintuitive to me; the syntax diagram just
changes from

LOCK ... [ IN lockmode MODE ] [ NOWAIT ]

to

LOCK ... [ IN lockmode MODE [ NOWAIT ] ]

If it had been that way to start with, nobody would have questioned it.

In any case I'd rather break apps using "LOCK foo NOWAIT" than break
every application using any form of LOCK at all, which is what I think
your proposal will amount to in practice. People aren't that eager to
write useless noise words, which is what TABLE has been up to now in
this command.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-01-14 19:49:29 Re: Database file copy
Previous Message Robert Haas 2011-01-14 19:44:39 Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.