Re: -f <output file> option for pg_dumpall
elein <elein@varlena.com>
From: elein <elein@varlena.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Neil Conway <neilc@samurai.com>, Tom Lane <tgl@sss.pgh.pa.us>, Dave Page <dpage@postgresql.org>, David Fetter <david@fetter.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2007-01-23T00:05:49Z
Lists: pgsql-hackers
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? --elein