From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Dumping roles improvements? |
Date: | 2011-10-12 04:43:44 |
Message-ID: | 8922.1318394624@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> The reason I want to have the dependant roles created as part of a
> database dump is so that we can ship around dump files as a single file,
> and restore them with a single command. This is considerably simpler
> than the current requirements, which are:
> 1. pg_dumpall the roles
> 2. pg_dump the database
> 3. tar both files
> 4. ship file
> 5. untar both files
> 6. psql the role file
> 7. pg_restore the database file
I don't find this terribly convincing. I can see the rationales for two
endpoint cases: (1) restore these objects into exactly the same
ownership/permissions environment that existed before, and (2) restore
these objects with the absolute minimum of ownership/permissions
assumptions. The latter case seems to me to be covered already by
--no-owner --no-privileges. Cases in between those endpoints seem
pretty special-purpose, and I don't want to buy into the assumption that
we should fix them by creating a plethora of --do-it-joshs-way switches.
Can we invent something comparable to the --list/--use-list mechanism,
that can handle a range of use cases with a bit more manual effort?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-10-12 05:34:22 | Re: Overhead cost of Serializable Snapshot Isolation |
Previous Message | Robert Haas | 2011-10-12 04:36:10 | Re: Index only scan paving the way for "auto" clustered tables? |