Re: pgpool versus sequences

Excerpts from Tom Lane's message of jue jun 02 11:10:00 -0400 2011:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
> >> That's a lot of work for a purely cosmetic issue, though.  What would be
> >> trivial is to let this work:
> >> 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.
> 
> No it wouldn't.  You seem to be imagining that sequences live in a
> different namespace from tables, but they don't.  There can only be one
> relation that "s1" will refer to for any search_path setting.

Doh, I see that I messed up and reversed the schemas in the search_path
line above.  If I fix that I get the expected error:

alvherre=# set search_path to 'public', 'public_too';
SET
alvherre=# lock s1;
ERROR:  «s1» no es una tabla

("s1" is not a table).  What I was imagining was that LOCK was using
search path to look only for tables and ignoring sequences.

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