Zhe-Wei Jiang <jrreinhardt@gmail.com> writes:
>> I read the GSoC ideas page and think the only one I'm possibly to help for
>> now is
>> "Rewrite (add) pg_dump and pg_restore utilities as libraries (.so, .dll &
>> .dylib)",
>> while I'm still not clear with the whole postgreSQL project.
>>
>> If my understanding is correct, taking pg_dump as an example, this should
>> include refactoring the pg_dump.c and rewrite the Makefile to make it as
>> shared libraries.
>> Do I miss anything?
The reason that that project has gone untouched for upwards of ten years
is that it's not just a large coding project, but involves a lot of
complex API design with uncertain goals. It's not very clear what
features people would want from a "pg_dump library", though one capability
that gets mentioned often is the ability to extract the SQL definition
for a single object. So before anything else you'd need to identify a
satisfactory set of library capabilities. The next nasty problem is that
pg_dump has a large set of odd behaviors that have evolved for good and
sufficient reason, and that we'd not want to give up, but that it's not
clear whether anyone else would want --- and they'd complicate any API
definition quite a bit. One example is that pg_dump knows how to dump
objects in a safe order to avoid forward references. If there turn out
to be circular references (which arise in more cases than you might think)
it even knows how to split certain kinds of objects into multiple
commands so as to break the circularity. How would we expose all that?
The features for parallel pg_dump and pg_restore are another thing that
doesn't seem to fit all that well into a clean library API. But how much
of this should actually be in a library, rather than in the wrapper
programs?
So while this is certainly a worthwhile task, it's not one to
underestimate the scope and difficulty of.
regards, tom lane