On Mon, May 2, 2016 at 10:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Ouch. Well, I think the first thing to do here might be to reconsider whether the footprint could be cut down. Removing the dependency on SPI seems like a good idea even if we do nothing else. Nailing the catalogs to a snapshot isn't crazy - the logical decoding stuff does it already - but having such a wide dependency footprint does not seem especially good. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
