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

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>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER DATABASE vs pg_dump
Date: 2008-06-27 15:34:56
Message-ID: 486508A0.1010007@archonet.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Richard Huxton <dev(at)archonet(dot)com> writes:
>> Is it desirable that pg_dump doesn't dump config settings set via ALTER 
>> DATABASE?
> 
> Well, it's intentional anyway: that's handled by pg_dumpall.  The basic
> design is that anything that can be seen from "outside" a specific
> database is handled on the pg_dumpall side.

Well, global settings and per-user settings are clearly global. I'm not 
sure that per-database settings are "logically" global, although I'll 
accept that's how they're stored.

At present it means you can't reliably do:
  DROP DATABASE foo;
  pg_restore --create foo.dump
I'd then have to either hand edit the dumpall dump or wade through a 
bunch of errors checking that none of them were relevant.

>> I just got bitten by a DateStyle not being restored on my test DB
> 
> You could also get bitten by not having restored users or tablespaces
> that the dump depends on, so I'm not sure there's a strong argument
> here for refactoring the responsibility.

Yep, but that will give you a "no such role" error when you try to 
restore. This is a situation where you can restore without errors and 
end up with different behaviour: dd/mm/yyyy vs mm/dd/yyyy or text-search 
stop-words changing.

-- 
   Richard Huxton
   Archonet Ltd

In response to

Responses

pgsql-hackers by date

Next:From: Florian G. PflugDate: 2008-06-27 15:44:36
Subject: Re: VirtualXactLockTableInsert
Previous:From: Hiroshi SaitoDate: 2008-06-27 15:16:30
Subject: Re: MSVC 2003 compile error with pg8.3.3

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