Paul Ramsey <pramsey@cleverelephant.ca> writes:
> ... I think the postgres_fdw extension should pass user-defined
> functions and operators, but only when it knows those functions and
> operators exist at the remote. One way would be to ask the remote what
> extensions it has, but the overhead of doing that is a bit high. A
> simpler way would be to just have the DBA declare what extensions the
> remote will have, when she creates the server definition, for example:
[ For the record, this idea was discussed a bit at PGCon. ]
The key question here is whether filtering functions/operators at the
level of extensions is a good design. It seems to me like a reasonable
compromise between flexibility and ease of use, but others might see it
differently. Josh Berkus indicated that he would also want a way to
mark individual functions/operators as transmittable, but clearly that
would not scale very well to large extensions like PostGIS. I don't
feel a need to insist that Paul include such a feature in his patch
(unless he wants to, of course) --- per-function marking seems like a
separate, though related, feature.
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.
(Presumably, only immutable functions would get transmitted, even if there
are mutable functions present in a marked extension.)
regards, tom lane
