Re: LOCK for non-tables - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: LOCK for non-tables
Date
Msg-id 1295038959.23290.113.camel@ebony
Whole thread Raw
In response to Re: LOCK for non-tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2011-01-14 at 15:46 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
> >> No, that will not work at all.  LOCK has to be a utility command.
> 
> > But it doesn't break the use case for locking sequences, ISTM.
> 
> You haven't stated what you think that use case is, but in any case
> I'm sure someone can come up with another one where not freezing
> the transaction snapshot *is* a consideration.

> > Anyway, any suggestion that randomly breaks user applications is not
> > good. If there is a good reason to do that, OK, but I don't see that
> > here. 
> 
> The good reason is adding functionality.  Or is it your position that
> the functionality under discussion is not worth any syntax breakage,
> no matter how narrowly circumscribed?  

I'm willing to listen to a clear restatement of the functionality being
added, so we can compare that to what we will lose. Currently, IMHO, the
importance of the new functionality seems low and the effect of breakage
is high for our users.

And I'm also interested in exploring other ways that give us the
functionality requested without the breakage.

Evolution, not revolution.

> If we take that position then
> we can drop this whole thread, because nothing's going to happen.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Srini Raghavan
Date:
Subject: Re: Database file copy
Next
From: Tom Lane
Date:
Subject: Re: LOCK for non-tables