Skip site navigation (1) Skip section navigation (2)

Re: pgsql_fdw, FDW for PostgreSQL server

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Robert Haas *EXTERN*" <robertmhaas(at)gmail(dot)com>,"Shigeru Hanada" <shigeru(dot)hanada(at)gmail(dot)com>
Cc: "Kohei KaiGai" <kaigai(at)kaigai(dot)gr(dot)jp>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>,"Martijn van Oosterhout" <kleptog(at)svana(dot)org>,"PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Date: 2011-11-29 09:25:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas wrote:
> 2011/11/28 Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)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

Laurenz Albe

In response to


pgsql-hackers by date

Next:From: Albe LaurenzDate: 2011-11-29 12:17:01
Subject: Re: review: CHECK FUNCTION statement
Previous:From: Daniel FarinaDate: 2011-11-29 08:37:07
Subject: Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group