Re: set search_path and pg_dumpall

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

In response to

Browse pgsql-hackers by date

  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?