Re: pg_dump and search_path

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Aug 10, 2015 at 1:10 PM, Steve Thames <sthames42@gmail.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