Re: Extension support for postgres_fdw

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 6/20/15 12:19 PM, Tom Lane wrote:
>> Note that no matter what the details are, something like this is putting
>> the onus on the DBA to mark as transmittable only functions that actually
>> are safe to transmit, ie they exist*and have identical semantics* on the
>> remote. I think that's fine as long as it's clearly documented.

> That seems like potentially a lot of extra work. We have the actual
> function body/definition for all but C functions, perhaps we could
> automatically map calls when the definitions are identical.

Huh? No, we don't have that, and even if we did,

(1) 95% of the functions of interest *are* C functions.

(2) It's probably unsafe ever to transmit non-C functions; there are too
many ways in which PL-language functions might be environment sensitive.
To take just one example, postgres_fdw runs the remote session with a
restricted search_path, which may not be what user-defined functions are
expecting.

(3) In general, determining the behavior of a function is equivalent to
solving the halting problem. SQL-language functions with sufficiently
simple bodies might be an exception --- but those probably got inlined
into the query before the FDW ever saw them, so it's irrelevant whether
we could deduce that they're safe to transmit.

It's possible that at some point we'd let the DBA override (2) and mark PL
functions as transmittable anyway; but for certain, this will be on an
"if you break it you get to keep both pieces" basis. We'd be nuts to do
it automatically.

regards, tom lane