Re: pg_dump and search_path

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 10, 2015 at 1:10 PM, Steve Thames <sthames42(at)gmail(dot)com> wrote:
>> Please consider making the arbitrary determination of search_path by pg_dump
>> an optional behavior. Or better yet, just have it generate a backup that
>> accurately reflects the database it is backing up.

> Hmm, I don't think it's a question of making it optional. I think the
> current behavior is just a bug, and should be fixed.

It is not a bug, and as far as I can see what Steve is complaining about
isn't even pg_dump's behavior: it is just how regclass constants work.
regclass_out only qualifies the name if it wouldn't be found in the
current search path. This is a display behavior and has nothing to do
with what the actual value of the constant is:

regression=# create schema s1;
CREATE SCHEMA
regression=# create table s1.t1 (f1 serial);
CREATE TABLE
regression=# \d s1.t1
Table "s1.t1"
Column | Type | Modifiers
--------+---------+----------------------------------------------------
f1 | integer | not null default nextval('s1.t1_f1_seq'::regclass)

regression=# set search_path = s1;
SET
regression=# \d s1.t1
Table "s1.t1"
Column | Type | Modifiers
--------+---------+-------------------------------------------------
f1 | integer | not null default nextval('t1_f1_seq'::regclass)

Now, if pg_dump produced a file that failed to restore this state
of affairs correctly, that would be a bug. But I have seen no
evidence suggesting that it doesn't get it right. The way that the
commands are spelled in the dump file is an implementation detail.

regards, tom lane