Re: Refactor pg_dump as a library?

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The problem with that approach is that then you are talking about building
>> duplicate copies of entire layers of the system.  For example, namespace.c
>> would have to be duplicated into one copy that uses syscache and one that
>> uses this not-quite-cache.  If it were *only* syscache.c that had to be
>> duplicated, probably this would work, but ruleutils.c depends on an awful
>> lot of code above that level.  Indeed, if it did not, the idea of
>> reimplementing it on the client side wouldn't be so unattractive.

> Urgh.  Does ruleutils.c really depend on everything in namespace.c?

Indirectly, probably most of it.  For example, it uses format_type_be()
which depends on TypeIsVisible(), and it uses func_get_detail()
which depends on FuncnameGetCandidates().  And it's those intermediate
functions that are really bloating the depends-on footprint.  As things
stand, ruleutils depends on significant fractions of backend/catalog/
and backend/parser/, all of which would have to be rewritten if you'd
like to make it use some alternate catalog-access infrastructure.

But really the killer point here is that it uses SPI in some places.
I've always wondered whether that was a good design choice, but right
now that implicates just about the whole backend.
        regards, tom lane