Re: -f <output file> option for pg_dumpall

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dave Page" <dpage(at)postgresql(dot)org>
Cc: "David Fetter" <david(at)fetter(dot)org>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: -f <output file> option for pg_dumpall
Date: 2007-01-06 17:16:43
Message-ID: 3963.1168103803@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Dave Page" <dpage(at)postgresql(dot)org> writes:
>> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> I think forking a separate
>> pg_dump for each database is a perfectly fine arrangement, and should be
>> left alone.

> Hmm, would you be happy with my original proposal to add an append option to pg_dump?

I don't object to it in principle, but I think a bit more thought is
needed as to what's the goal. A stupid "append" option would be enough
for pg_dumpall's current capabilities (ie, text output only) --- but is
it reasonable to consider generalizing -Fc and -Ft modes to deal with
multiple databases, and if so how would that need to change pg_dump's
API? (I'm not at all sure this is feasible, but let's think about it
before plastering warts onto pg_dump, not after.)

> I'd also like to allow separate dumping of roles and tablespaces, and allow a default db to be specified instead of postgres/template1.

Can't get excited about either, but no objection.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-01-06 17:16:44 Re: COPY with no WAL, in certain circumstances
Previous Message Bruce Momjian 2007-01-06 16:05:21 Re: COPY with no WAL, in certain circumstances