Re: pgsql_fdw, FDW for PostgreSQL server

(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