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
