Re: pgpool versus sequences - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pgpool versus sequences
Date
Msg-id 1307026309-sup-4021@alvh.no-ip.org
Whole thread Raw
In response to Re: pgpool versus sequences  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
> > <alvherre@commandprompt.com> wrote:
> >> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
> >> to have.
> 
> > It cause a grammar conflict.
> 
> That's a lot of work for a purely cosmetic issue, though.  What would be
> trivial is to let this work:
> 
> regression=# create sequence s1;
> CREATE SEQUENCE
> regression=# begin;
> BEGIN
> regression=# lock table s1;
> ERROR:  "s1" is not a table

Yeah, though it'd be nice to avoid this:

alvherre=# create schema public_too;
CREATE SCHEMA
alvherre=# set search_path to 'public_too', 'public';
SET
alvherre=# create table public_too.s1 ();
CREATE TABLE
alvherre=# create sequence public.s1;
CREATE SEQUENCE
alvherre=# begin;
BEGIN
alvherre=# lock s1;
LOCK TABLE

At this point we have a lock on the table, but if we change LOCK to also
look for sequences, the behavior would change.  At the very least, the
command tag should be different.

Hopefully few people name sequences the same as tables ...

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: vacuum and row type
Next
From: Pavel Golub
Date:
Subject: Re: PQdeleteTuple function in libpq