On Thu, Jul 16, 2015 at 12:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paqu...@gmail.com> writes:
>> On Thu, Jul 16, 2015 at 3:43 AM, Paul Ramsey <pram...@cleverelephant.ca>
>> wrote:
>>> Attached is a patch that implements the extension support discussed at
>>> PgCon this year during the FDW unconference sesssion.
>
> ...
>
>> Thinking a bit wider, why is this just limited to extensions?
>
> The basic issue here is "how can a user control which functions/operators
> can be sent for remote execution?".
Yep.
> While it's certainly true that
> sometimes you might want function-by-function control of that, Paul's
> point was that extension-level granularity would be extremely convenient
> for PostGIS, and probably for other extensions. I don't see anything
> wrong with that --- and I don't think that we should insist that Paul's
> patch implement both cases. Somebody else who really needs
> function-by-function control can do the dogwork of figuring out a
> reasonable API for that.
Well, you could for example pass a JSON string (that's fashionable
these days) that sets up a list of authorized objects per category
instead, like:
authorized_objects = {functions:["foo_oid","foo2_oid"],
operators:["ope1_oid","ope2_oid"]}
> Disclaimer 1: Paul and I discussed this back at PGCon, and I encouraged
> him to send in his patch.
>
> Disclaimer 2: I haven't read the patch and don't mean to vouch for any
> implementation details. But the functional spec of "allow remote
> execution of functions belonging to named extensions" seems sane to me.
Well, I am just questioning the extensibility of the proposed
interface, not saying that this is a bad thing :)
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
