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. (While we're on the subject, this would also present a good opportunity to make pg_dump's command-line interface a little more sane. I wonder if pg_dump's syntax has gotten sufficiently complicated that some users might prefer to specify behavior via a configuration file, rather than a long string of command-line options.) -Neil ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
