From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Page <dpage(at)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: -f <output file> option for pg_dumpall |
Date: | 2007-01-15 15:13:16 |
Message-ID: | 45AB9A0C.6000204@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway wrote:
> On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote:
>
>> I don't think they need to be integrated any time soon, but if we were
>> to design pg_dump and pg_dumpall from scratch, it seems more logical to
>> use a single program
>>
>
> On thinking about this some more, it might be useful to factor much of
> pg_dump's logic for reconstructing the state of a database into a shared
> library. This would make it relatively easy for developers to plug new
> archive formats into the library (in addition to the present 3 archive
> formats), or to make use of this functionality in other applications
> that want to reconstruct the logical state of a database from the
> content of the system catalogs. We could then provide a client app
> implemented on top of the library that would provide similar
> functionality to pg_dump.
>
> Moving pg_dump's functionality into the backend has been suggested in
> the past (and rejected for good reason), but I think this might be a
> more practical method for making the pg_dump logic more easily reusable.
>
>
>
I like this idea. For example, we might usefully map some of this to
psql \ commands, without having to replicate the underlying logic.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Carlo Stonebanks | 2007-01-15 15:14:18 | Re: ODBC: how to change search_path in DSN? |
Previous Message | Alvaro Herrera | 2007-01-15 14:56:52 | Re: Autovacuum improvements |