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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
