On Mon, May 2, 2016 at 10:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
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