Re: Refactor pg_dump as a library?

On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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.

Urgh. Does ruleutils.c really depend on everything in namespace.c?
When I last looked at this I had the idea that at least a good chunk
of ruleutils.c had only limited outside dependencies that might not be
too tough to manage. However, if that's not true, then I agree that's
a problem for this approach.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company