(2011/12/13 20:04), Heikki Linnakangas wrote:
> The SQL/MED spec handles this with the concept of "routine mappings".
> There is syntax for defining which remote "routines", meaning functions,
> correspond local functions:
>
> CREATE ROUTINE MAPPING <routine mapping name> FOR <specific routine
> designator>
> SERVER <foreign server name> [ <generic options> ]
>
> <generic options> is FDW-specific, I'd imagine the idea is to give the
> name of the corresponding function in the remote server. It doesn't say
> anything about collations, but you could have extra options to specify
> that a function can only be mapped under C collation, or whatever.
I considered ROUTINE MAPPING for other RDBMS before, and thought that
having order of parameter in generic options would be necessary. It's
also useful for pgsql_fdw to support pushing down user-defined
functions. Maybe built-in format() function suits for this purpose?
> It seems tedious to specify that per-server, though, so we'll probably
> still want to have some smarts in the pgsql_fdw to handle the built-in
> functions and types that we know to be safe.
One possible idea is having default mapping with serverid = InvalidOid,
and override them with entries which has valid server oid. Such default
mappings can be loaded during CREATE EXTENSION.
> I've been talking about functions here, not operators, on the assumption
> that we can look up the function underlying the operator and make the
> decisions based on that.
It's interesting viewpoint to think operator notation is syntax sugar of
function notation, e.g. "A = B" -> "int4eq(A, B)". Routine mappings
seem to work for operators too.
Regards,
--
Shigeru Hanada
