On Fri, 2011-01-14 at 15:46 -0500, Tom Lane wrote: > Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
