Re: pgpool versus sequences

Excerpts from Tom Lane's message of jue jun 02 11:10:00 -0400 2011:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support