Re: Custom format for pg_dumpall

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Custom format for pg_dumpall
Date: 2004-03-16 16:13:27
Message-ID: 200403161613.i2GGDR524812@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Added to TODO:

* Allow pg_dumpall to use non-text output formats

---------------------------------------------------------------------------

Philip Warner wrote:
> 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 |/
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sailesh Krishnamurthy 2004-03-16 16:20:14 Re: Reducing expression evaluation overhead
Previous Message Tom Lane 2004-03-16 16:11:17 Re: Some one deleted pg_database entry how to fix it?