On Thu, Sep 29, 2016 at 11:29 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > The fundamental thing we have to do in order to move forward on this is > to rethink what's the division of labor between pg_dump and pg_dumpall. > I find the patch as presented quite unacceptable because it's made no > effort to do that (or even to touch the documentation). > > What do people think of this sketch: > > 1. pg_dump without --create continues to do what it does today, ie it just > dumps objects within the database, assuming that database-level properties > will already be set correctly for the target database. > > 2. pg_dump with --create creates the target database and also sets all > database-level properties (ownership, ACLs, ALTER DATABASE SET, etc etc). > > 3. pg_dumpall loses all code relating to individual-database creation > and property setting and instead relies on pg_dump --create to do that. > This would leave only the code relating to "pg_dumpall -g" (ie, dump roles > and tablespaces) within pg_dumpall itself.
Seems like a good sketch. > One thing that would still be messy is that presumably "pg_dumpall -g" > would issue ALTER ROLE SET commands, but it's unclear what to do with > ALTER ROLE IN DATABASE SET commands. Should those become part of > "pg_dump --create"'s charter? It seems like not, but I'm not certain. I could go either way on this. > Another thing that requires some thought is that pg_dumpall is currently > willing to dump ACLs and other properties for template1/template0, though > it does not invoke pg_dump on them. If we wanted to preserve that > behavior while still moving the code that does those things to pg_dump, > pg_dump would have to grow an option that would let it do that. But > I'm not sure how much of that behavior is actually sensible. I'm not sure, either, but it's usually bad when dump-and-restore doesn't dump-and-restore things which a user might reasonably have changed. That tends to lead to bug reports and/or pg_upgrade failures. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
