Robert Haas wrote: > 2011/11/28 Shigeru Hanada <shigeru.han...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
