(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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
