Robert Haas wrote:
> 2011/11/28 Shigeru Hanada <shigeru.hanada@gmail.com>:
>> I agree that allowing users to control which function/operator should be
>> pushed down is useful, but GUC seems too large as unit of switching
>> behavior. "Routine Mapping", a mechanism which is defined in SQL/MED
>> standard, would be the answer for this issue. It can be used to map a
>> local routine (a procedure or a function) to something on a foreign
>> server. It is like user mapping, but it has mapping name. Probably it
>> would have these attributes:
>>
>> pg_catalog.pg_routine_mapping
>> rmname name
>> rmprocid regproc
>> rmserverid oid
>> rmfdwoptions text[]
>>
>> If we have routine mapping, FDW authors can provide default mappings
>> within extension installation, and users can customize them. Maybe FDWs
>> will want to push down only functions/operators which have routine
>> mapping entries, so providing common routine which returns mapping
>> information of given function/operator, say GetRoutineMapping(procid,
>> serverid), is useful.
>>
>> Unfortunately we don't have it at the moment, I'll fix pgsql_fdw so that
>> it pushes down only built-in operators, including scalar-array operators.
>
> One difficulty here is that even very simple operators don't
> necessarily mean the same thing on both sides. In my last job we had
> a Microsoft SQL database where string equality was case insensitive,
> and a PostgreSQL database where it wasn't.
I think that this is not always safe even from PostgreSQL to PostgreSQL.
If two databases have different collation, "<" on strings will behave
differently.
Yours,
Laurenz Albe
