Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Date
Msg-id 10750.1214797456@sss.pgh.pa.us
Whole thread Raw
In response to Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)  (Richard Huxton <dev@archonet.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Robert Treat wrote:
>> Certainly not desired by a number of people I have talked to, but I don't have 
>> much hope in seeing the behavoir change... perhaps someday if we get around 
>> to merging pg_dump and pg_dumpall....

> I have never heard anyone say the current behavior is something they desired.

So put forward a worked-out proposal for some other behavior.

My first thought is that the -c and -C options create a lot of the
issues in this area.  -c in particular is evidently meant for merging a
dump into a database that already contains unrelated objects.  (In fact
you could argue that the *default* behavior is meant for this, -c just
changes the result for conflicts.)  It seems unlikely that having
pg_dump issue ALTER DATABASE SET commands is a good idea in all of these
scenarios.

I'm also wondering why it'd be bright to treat ALTER ... SET properties
different from, say, database owner and encoding properties.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Next
From: Tom Lane
Date:
Subject: A new take on the foot-gun meme