At 11:12 AM 16/03/2004, Tom Lane wrote:
>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 |/