Hannu Krosing wrote:
> On 04/10/2013 11:02 PM, Alvaro Herrera wrote:
> >Peter Eisentraut wrote:
> >
> >>I think the main uses cases mentioned in connection with this idea are
> >>usually in the direction of finer-grained control over what gets dumped
> >>and how. But making pg_dump into a library would not necessarily
> >>address that.
> >There's also the matter of embedding pg_dump into other programs. For
> >example, calling the pg_dump executable from inside pgAdmin is a rather
> >messy solution to the problem.
>
> 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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
