Robert Haas <robertmh...@gmail.com> writes: > On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers