On July 17, 2015 at 12:49:04 AM, Simon Riggs (si...@2ndquadrant.com(mailto:si...@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 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
