Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Hannu Krosing wrote:
>> Natural solution to this seems to move most of pg_dump functionality
>> into backend as functions, so we have pg_dump_xxx() for everything
>> we want to dump plus a topological sort function for getting the
>> objects in right order.
> This idea doesn't work because of back-patch considerations (i.e. we
> would not be able to create the functions in back branches, and so this
> new style of pg_dump would only work with future server versions). So
> pg_dump itself would have to retain capability to dump stuff from old
> servers. This seems unlikely to fly at all, because we'd be then
> effectively maintaining pg_dump in two places, both backend and the
> pg_dump source code.
There are other issues too, in particular that most of the backend's
code tends to work on SnapshotNow time whereas pg_dump would really
prefer it was all done according to the transaction snapshot. We have
got bugs of that ilk already in pg_dump, but we shouldn't introduce a
bunch more. Doing this right would therefore mean that we'd have to
write a lot of duplicative code in the backend, ie, it's not clear that
we gain any synergy by pushing the functionality over. It might
simplify cross-backend-version issues (at least for backend versions
released after we'd rewritten all that code) but otherwise I'm afraid
it'd just be pushing the problems somewhere else.
In any case, "push it to the backend" offers no detectable help with the
core design issue here, which is figuring out what functionality needs
to be exposed with what API.
regards, tom lane
