Re: [PATCH] postgres_fdw extension support

Поиск
Список
Период
Сортировка
От Paul Ramsey
Тема Re: [PATCH] postgres_fdw extension support
Дата
Msg-id etPan.55a8fa4b.643c9869.f869@Crane.local
обсуждение исходный текст
Ответ на Re: [PATCH] postgres_fdw extension support  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: [PATCH] postgres_fdw extension support  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
 
On July 17, 2015 at 12:49:04 AM, Simon Riggs (simon@2ndquadrant.com(mailto:simon@2ndquadrant.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
showup with the desire to fiddle them :) if marking extensions is not considered a good API, then I’d lean towards (a)
beingable 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
(addinga 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
operatorsfor 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
threadon this topic the problem of forwarding arbitrary user-defined PL/PgSQL functions was brought up. In passing it
wasmentioned 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
policyis required for any kind of additional forwarding would be interesting. Maybe IMMUTABLE/STABLE/VOLATILE doesn’t
actuallycapture what it is that makes a function/op FORWARDABLE or not. 
 







В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCH] postgres_fdw extension support