Robert Haas <robertmh...@gmail.com> writes: > On Mon, Aug 10, 2015 at 1:10 PM, Steve Thames <sthame...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers