Skip site navigation (1) Skip section navigation (2)

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

From: Richard Huxton <dev(at)archonet(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Date: 2008-06-30 08:38:08
Message-ID: 48689B70.9040307@archonet.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> 
> So put forward a worked-out proposal for some other behavior.

OK

> 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.

Can't comment on --clean since I don't use it. I've always assumed it's 
for the case where you don't have a user with permissions to 
drop/recreate a database (e.g. web hosting).

IMHO the time a dump/restore should be issuing ALTER...SET on a database 
is when it has issued the corresponding CREATE DATABASE. If you want to 
tweak this sort of thing, just manually create the database with 
whatever options you want and don't use --create.

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

Not sure what you mean here.

-- 
   Richard Huxton
   Archonet Ltd

In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-06-30 11:07:04
Subject: Re: TODO item: Allow data to be pulled directly from indexes
Previous:From: Heikki LinnakangasDate: 2008-06-30 07:33:36
Subject: Re: TODO item: Allow data to be pulled directly from indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group