Robert Haas <robertmh...@gmail.com> writes:
> 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.
>>> 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.
>> 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.
Meh. I'd be the first to say that probably a lot of that is because it
was convenient; but I don't see any way to avoid it without duplicating
vast quantities of code, which does not sound like a great idea from a
maintainability standpoint. And have we mentioned the fact that some of
this code looks directly at the catalogs because there's no suitable
syscache?
Really I think the idea of fixing this with an alternate syscache is
a nonstarter.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
