Re: [PATCH] postgres_fdw extension support

 
On July 17, 2015 at 12:49:04 AM, Simon Riggs (simon(at)2ndquadrant(dot)com(mailto:simon(at)2ndquadrant(dot)com)) wrote:
> On 17 July 2015 at 01:23, Michael Paquier wrote:
>
> > > Well, as I see it there’s three broad categories of behavior available:
> > >
> > > 1- Forward nothing non-built-in (current behavior)
> > > 2- Use options to forward only specified non-built-in things (either in
> > > function chunks (extensions, as in this patch) or one-by-one (mark your
> > > desired functions / ops)
> > > 3- Forward everything if a “forward everything” option is set
> >
> > Then what you are describing here is a parameter able to do a switch
> > among this selection:
> > - nothing, which is to check on built-in stuff
> > - extension list.
> > - all.
>
> "all" seems to be a very blunt instrument but is certainly appropriate in some cases
>
> I see an intermediate setting, giving four categories in total
>
> 0. Nothing, as now
> 1. Extension list option on the Foreign Server
> 2. Extension list option on the Foreign Data Wrapper, applies to all Foreign Servers of that type
> 3. All extensions allowed

I feel like a lot of knobs are being discussed for maximum configurability, but without knowing if people are going to show up with the desire to fiddle them :) if marking extensions is not considered a good API, then I’d lean towards (a) being able to toggle global fowarding on and off combined with (b) the ability to mark individual objects forwardable or not. Which I see, is almost what you’ve described.

There’s no facility to add OPTIONS to an EXTENSION right now, so this capability seems to be very much server-by-server (adding a FDW-specific capability to the EXTENSION mechanism seems like overkill for a niche feature addition).

But within the bounds of the SERVER, being able to build combinations of allowed/restricted forwarding is certainly powerful,

  CREATE SERVER foo 
    FOREIGN DATA WRAPPER postgres_fdw 
    OPTIONS ( host ‘localhost’, dbname ‘foo’, forward ‘all -postgis’ );

  CREATE SERVER foo 
    FOREIGN DATA WRAPPER postgres_fdw 
    OPTIONS ( host ‘localhost’, dbname ‘foo’, forward ’none +postgis’ );

  CREATE SERVER foo 
    FOREIGN DATA WRAPPER postgres_fdw 
    OPTIONS ( host ‘localhost’, dbname ‘foo’, forward ’none +&&’ );

Once we get to individual functions or operators it breaks down, since of course ‘&&’ refers to piles of different operators for different types. Their descriptions would be unworkably verbose once you have more than a tiny handful.

I’m less concerned with configurability than just the appropriateness of forwarding particular functions. In an earlier thread on this topic the problem of forwarding arbitrary user-defined PL/PgSQL functions was brought up. In passing it was mentioned that maybe VOLATILE functions should *never* be forwarded ever. Or, that only IMMUTABLE functions should be *ever* be forwarded. Since PostGIS includes a generous mix of all kinds of functions, discussing whether that kind of policy is required for any kind of additional forwarding would be interesting. Maybe IMMUTABLE/STABLE/VOLATILE doesn’t actually capture what it is that makes a function/op FORWARDABLE or not.