Re: -f <output file> option for pg_dumpall

Andrew Dunstan <andrew@dunslane.net>

From: "Andrew Dunstan" <andrew@dunslane.net>
To: "Neil Conway" <neilc@samurai.com>, "Dave Page" <dpage@postgresql.org>, "David Fetter" <david@fetter.org>, "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Date: 2007-01-23T00:36:14Z
Lists: pgsql-hackers
elein wrote:
> On Mon, Jan 15, 2007 at 10:13:16AM -0500, Andrew Dunstan wrote:
>>
>>
>> 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.
>
> Don't we already do this with the .psqlrc file?
>

No. \ commands are implemented in C code.

cheers

andrew