Message-ID: <4C906F81.4010108@enterprisedb.com>
Date: Wed, 15 Sep 2010 10:02:25 +0300
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fi-FI;
	rv:1.9.1.10) Gecko/20100619 Iceowl/1.0b1 Icedove/3.0.5
MIME-Version: 1.0
To: SAKAMOTO Masahiko <sakamoto.masahiko@oss.ntt.co.jp>
CC: pgsql-hackers@postgresql.org
Subject: Re: patch: SQL/MED(FDW) DDL
References: <4C905DB0.6040302@oss.ntt.co.jp>
In-Reply-To: <4C905DB0.6040302@oss.ntt.co.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

On 15/09/10 08:46, SAKAMOTO Masahiko wrote:
> This is a proposal patch for SQL/MED for 9.1.
> 
> At the prev. CF, this patch had so many features to make it hard
> to review all of them.  So I devided it into smaller parts:
>   (1) foreign table DDL support (this proposal):
>       - support for foreign table DDL syntax (CREATE/ALTER FOREIGN TABLE)
>       - Definition of FDW routine interface and system catalogs for it.
>   (2) SELECT support for external PostgreSQL tables.
> 
> 
> First of all, I'd like to discuss and make agreement on the basic design
> and its implementation for FDW interface.
> Comments and ideas would be very appriciated, especially
> on how system catalog stores the information about
> foreign tables, server, and user mappings.

In my mind the key question is: what does the API for writing foreign
data wrappers look like? I couldn't figure that out by looking at the patch.

The API needs to be simple and version-independent, so that you can
write simple wrappers like the flat file wrapper easily. At the same
time, it needs to be very flexible, so that it allows safely pushing
down all kinds constructs like functions, aggregates and joins. The
planner needs to know which constructs the wrapper can handle and get
cost estimates for the foreign scans. Those two goals are at odds.

I've been thinking about that for some time. Here's one sketch I made a
while ago:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00395.php.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com