Re: pgsql_fdw, FDW for PostgreSQL server - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pgsql_fdw, FDW for PostgreSQL server
Date
Msg-id CA+TgmoYpLHCFv44aHjp7=qzSempKJcyxC6L5eXi_GDtQcLrScw@mail.gmail.com
Whole thread Raw
In response to Re: pgsql_fdw, FDW for PostgreSQL server  (Shigeru Hanada <shigeru.hanada@gmail.com>)
Responses Re: pgsql_fdw, FDW for PostgreSQL server  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
List pgsql-hackers
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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: psql line number reporting from stdin
Next
From: Kohei KaiGai
Date:
Subject: Re: Prep object creation hooks, and related sepgsql updates