Re: LOCK for non-tables

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

On Fri, 2011-01-14 at 15:46 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-14 21:09:35 Re: LOCK for non-tables
Previous Message Srini Raghavan 2011-01-14 20:59:29 Re: Database file copy