That seems like it would complicate both pg_dump and pg_restore unduly. I'd rather keep both of them as simple one-database programs.
Sounds fine, if that's a design objective. But it is a different problem to definining the archive format of pg_dumpall.
To take just one objection, people are accustomed to be able to load a pg_dump from database foo into a database with a different name; that would be either impossible or very klugy if we do what you're thinking of.
Again, ISTM this is confusing user-interface with storage format.
While it is certainly possible to define a meta-archive format, ISTM that the existing archive format can handle multiple DBs with little or no work. Whether we choose to let pg_restore understand those files is another matter (personally I'd vote yes).
The current format has a (small) TOC, followed by the (large) data. I suggest that the TOC would become larger, and include entries for multiple DBs, each with some tag to indicate the DB it belonged to (db name?). In the case where the TOC has only one DB, it is almost identical to the current dump format except it has installation-wide settings as well. The latter case (at least) should be readable by pg_restore, but that is not necessary if you prefer to create a pg_restoreall which almost completely mimics pg_restore. In any case there needs to be the ability to select just one DB, just the user definitions etc similar to the existing pg_restore.
I don't see a lot of kludges here.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
