Re: Refactor pg_dump as a library?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Apr 15, 2016 at 2:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The problem here is the connection to syscache; changing the behavior
>> of that, in a general context, is very scary. What we might be able to
>> do that would satisfy pg_dump's needs is to invent a mode in which you
>> can run a read-only transaction that uses the transaction snapshot to
>> populate syscache (and then flushes the syscache at the end).

> I think that we could have an alternate set of functions which have
> the same interface as the syscache functions but using the transaction
> snapshot and don't actually cache anything, and it would be fine for
> what the pg_dump support functions need.

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.

regards, tom lane