Re: [PATCH] postgres_fdw extension support

From: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] postgres_fdw extension support
Date: 2015-07-21 17:52:01
Message-ID: etPan.55ae86c1.74b0dc51.4a53@Butterfly.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

 
On July 21, 2015 at 8:26:31 AM, Andres Freund (andres(at)anarazel(dot)de(mailto:andres(at)anarazel(dot)de)) wrote:
> On 2015-07-21 17:00:51 +0200, Andres Freund wrote:
> > On 2015-07-21 07:55:17 -0700, Paul Ramsey wrote:
> > > On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote:
> > > So, right after reading the options in postgresGetForeignRelSize,
> > > expand the extension list into a list of all ops/functions, in a
> > > sorted list, and let that carry through to the deparsing instead?
> >
> > I'd actually try to make it longer lived, i.e. permanently. And just
> > deallocate when a catcache callback says it needs to be invalidated;
> > IIRC there is a relevant cache.
>
> On second thought I'd not use a binary search but a hash table. If you
> choose the right key a single table is enough for the lookup.
>
> If you need references for invalidations you might want to look for
> CacheRegisterSyscacheCallback callers. E.g. attoptcache.c

> On 2015-07-21 08:32:34 -0700, Paul Ramsey wrote: 
> > Thanks! Reading some of the syscache callback stuff, one thing I’m not 
> > sure of is which SysCacheIdentifier(s) I should be registering 
> > callbacks against to ensure my list of funcs/procs that reside in 
> > particular extensions is kept fresh. I don’t see anything tracking the 
> > dependencies there 

> FOREIGNSERVEROID, and a new syscache on pg_extension.oid should suffice 
> I think. pg_foreign_server will be changed upon option changes and 
> pg_extension.oid on extension upgrades. 

> Since dependencies won't change independently of extension versions I 
> don't think we need to care otherwise. There's ALTER EXTENSION ... ADD 
> but I'm rather prepared to ignore that; if that's not ok it's trivial to 
> make it emit an invalidation. 

This hole just keeps getting deeper :) So,

- a HASH in my own code to hold all the functions that I consider “safe to forward” (which I’ll derive by reading the contents of the extensions the users declare)
- callbacks in my code registered using CacheRegisterSyscacheCallback on FOREIGNSERVEROID and __see_below__ that refresh my cache when called
- since there is no syscache for extensions right now, a new syscache entry for pg_extension.oid (and I ape things in syscache.h and syscache.c and Magic Occurs?)
- which means I can also CacheRegisterSyscacheCallback on the new EXTENSIONOID syscache
- and finally change my is_in_extension() to efficiently check my HASH instead of querying the system catalog

Folks are going to be OK w/ me dropping in new syscache entries so support my niche little feature?

ATB,

P

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-07-21 18:01:54 Re: Selectivity estimation for intarray with @@
Previous Message Tom Lane 2015-07-21 17:09:51 Re: What is HeapScanDescData.rs_initblock good for?