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

From Richard Huxton
Subject Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Date
Msg-id 4869E0A8.9040002@archonet.com
Whole thread Raw
In response to Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
Tom Lane wrote:
> Richard Huxton <dev@archonet.com> writes:
>> Tom Lane wrote:
>>> So put forward a worked-out proposal for some other behavior.
> 
>> IMHO the time a dump/restore should be issuing ALTER...SET on a database 
>> is when it has issued the corresponding CREATE DATABASE.
> 
> So pg_dump would produce this info when, and only when, you'd used
> --create?  I agree that it seems sensible in that case, I'm just
> wondering if that will cover all the use-cases.

Well, in the -Fc case you'd produce it always and pg_restore would only 
emit it when you --create.

The only time we need to restore per-database settings is if the 
database has been dropped. If you're not having the dump/restore 
re-create the database then presumably you've taken charge of the 
per-database settings.

> This would mean duplicating some functionality between pg_dump and
> pg_dumpall ... or maybe we could move all that logic over to pg_dump and
> have pg_dumpall use --create when invoking pg_dump.

--   Richard Huxton  Archonet Ltd


pgsql-hackers by date:

Previous
From: "Andrew Hammond"
Date:
Subject: Re: the un-vacuumable table
Next
From: Gregory Stark
Date:
Subject: Re: Planned obsolescence in identify_system_timezone()