Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
