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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Richard Huxton <dev(at)archonet(dot)com>
Subject: Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Date: 2008-06-30 03:44:16
Message-ID: 10750.1214797456@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-hackers by date

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