From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | ohp(at)pyrenet(dot)fr, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: set search_path and pg_dumpall |
Date: | 2004-01-19 19:11:32 |
Message-ID: | 9701.1074539492@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> I can't be the only one forsee frustration from users who typo the set
> search_path statement and then can't figure out why their tables aren't
> showing up... can we emit a warning that not all of the schemas in the
> search path were found?
Since no one else commented, I've followed your suggestion. As of CVS
tip, you get a NOTICE not ERROR in this case:
regression=# set search_path = public,z;
ERROR: schema "z" does not exist
regression=# create database foo;
CREATE DATABASE
regression=# alter database foo set search_path = public,z;
NOTICE: schema "z" does not exist
ALTER DATABASE
regression=# select datconfig from pg_database where datname = 'foo';
datconfig
---------------------------
{"search_path=public, z"}
(1 row)
If a bogus entry is present in the established search_path value, it's
just ignored (this was true already to handle "$user"):
regression=# \c foo
You are now connected to database "foo".
foo=# show search_path;
search_path
-------------
public, z
(1 row)
foo=# select current_schemas(true);
current_schemas
---------------------
{pg_catalog,public}
(1 row)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2004-01-19 19:35:57 | Old binary packages. |
Previous Message | Andrew Sullivan | 2004-01-19 19:07:46 | Re: What's planned for 7.5? |