Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 6D2E8B6181D for ; Thu, 2 Jun 2011 12:10:16 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 09282-02 for ; Thu, 2 Jun 2011 15:10:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 3AE66B6180E for ; Thu, 2 Jun 2011 12:10:09 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p52FA08d015727; Thu, 2 Jun 2011 11:10:00 -0400 (EDT) To: Alvaro Herrera cc: Robert Haas , Tatsuo Ishii , mangoo , "scott.marlowe" , "Kevin.Grittner" , pgsql-hackers Subject: Re: pgpool versus sequences In-reply-to: <1307026309-sup-4021@alvh.no-ip.org> References: <26909.1306965898@sss.pgh.pa.us> <27741.1306968830@sss.pgh.pa.us> <20110602.080816.460114267356667394.t-ishii@sraoss.co.jp> <1306971997-sup-5549@alvh.no-ip.org> <14930.1307025118@sss.pgh.pa.us> <1307026309-sup-4021@alvh.no-ip.org> Comments: In-reply-to Alvaro Herrera message dated "Thu, 02 Jun 2011 10:55:26 -0400" Date: Thu, 02 Jun 2011 11:10:00 -0400 Message-ID: <15726.1307027400@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201106/134 X-Sequence-Number: 188847 Alvaro Herrera 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. regards, tom lane