Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 0702B2E00A6 for ; Mon, 28 Apr 2008 09:04:39 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 13983-01-8 for ; Mon, 28 Apr 2008 09:04:27 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by developer.postgresql.org (Postfix) with ESMTP id B74DC2E00C8 for ; Mon, 28 Apr 2008 09:04:15 -0300 (ADT) Received: from perhan.alvh.no-ip.org (200-126-123-196.bk8-dsl.surnet.cl [200.126.123.196]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m3SC4pPi013514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Apr 2008 05:04:53 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 130B647C6D; Sun, 27 Apr 2008 20:05:41 -0400 (CLT) Date: Sun, 27 Apr 2008 20:05:41 -0400 From: Alvaro Herrera To: chester c young Cc: Tom Lane , sql pgsql Subject: Re: psql: no schema info Message-ID: <20080428000541.GC9074@alvh.no-ip.org> References: <23267.1209335819@sss.pgh.pa.us> <213749.31261.qm@web54304.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <213749.31261.qm@web54304.mail.re2.yahoo.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Mon, 28 Apr 2008 05:04:54 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/211 X-Sequence-Number: 30750 chester c young wrote: > # create table new_schema.table1( > # col1 integer default nextval( 'seq1' ) > # ); > > using old_schema.seq1, not new_schema.seq1 Yes, that's correct -- assuming you had an old_schema.seq1 sequence too. > and imho to make matters more difficult to troubleshoot: > > # \dt table1 -> does not show which schema for seq1 I agree it can be confusing if you're not looking for it. alvherre=# set search_path to old_s; SET alvherre=# \d new_s.table1 Tabla «new_s.table1» Columna | Tipo | Modificadores ---------+---------+----------------------------------- col1 | integer | default nextval('seq1'::regclass) Here, the nextval() is correctly _not_ qualified, because the current search path is the sequence's schema. But it is certainly confusing. You have to set the search_path to the table's search path for the problem to be obvious: alvherre=# set search_path to new_s; SET alvherre=# \d new_s.table1 Tabla «new_s.table1» Columna | Tipo | Modificadores ---------+---------+----------------------------------------- col1 | integer | default nextval('old_s.seq1'::regclass) alvherre=# \d table1 Tabla «new_s.table1» Columna | Tipo | Modificadores ---------+---------+----------------------------------------- col1 | integer | default nextval('old_s.seq1'::regclass) I'm not sure what's a good solution here. Perhaps the \d command should temporarily set the schema to something that would cause regclass to display qualified names all the time, when you passed it a qualified name (using SET LOCAL perhaps, but reverting to the original value after then \d is done). You can't just use a nonexistant schema or some kind of NULL or empty value, because SET rejects it. I can set it to $user, which is accepted but doesn't exist on my scratch database: alvherre=# set search_path to '$user'; SET alvherre=# \d new_s.table1 Tabla «new_s.table1» Columna | Tipo | Modificadores ---------+---------+----------------------------------------- col1 | integer | default nextval('old_s.seq1'::regclass) Another option would be to set it to the given schema, so that any name not on that schema is qualified. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support