Re: FDW-based dblink (WIP) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: FDW-based dblink (WIP)
Date
Msg-id 1253011951.18101.12.camel@fsopti579.F-Secure.com
Whole thread Raw
In response to FDW-based dblink (WIP)  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: FDW-based dblink (WIP)
List pgsql-hackers
On Wed, 2009-08-19 at 17:07 +0900, Itagaki Takahiro wrote:
> Here is a WIP patch for a foreign data wrapper based dblink.
> 
> It integrates dblink module into core and adds a new functionality,
> automatic transaction management. The new interface of dblink is
> exported by include/foreign/dblink.h. We can easily write a connector
> module for another database because we can reuse transaction and
> resource management parts in core.

This patch is listed in the commitfest, but I think the consensus was
that it needed some rework.  I think the idea is that we will have
support for syntax like

> Syntax to create FDW with connector is below:
>     CREATE FOREIGN DATA WRAPPER postgresql
>         VALIDATOR postgresql_fdw_validator
>         CONNECTOR postgresql_fdw_connector
>         OPTIONS (...);

in core, but the actual implementation of postgresql_fdw_connector would
be a loadable module.

Personally, I'm undecided whether the single-function connector
implementation is the best.  The other approach would be to use a
multiple-function interface based directly on the functions currently
provided by dblink.

More generally, what does this really buy us?  It doesn't advance the
SQL/MED implementation, because you are not adding, say, some kind of
CREATE FOREIGN TABLE support.  You are just changing the dblink
implementation to go through the FDW.  I would argue that it should be
the other way around: The FDW should go through dblink.




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Streaming Replication patch for CommitFest 2009-09
Next
From: Heikki Linnakangas
Date:
Subject: Re: Streaming Replication patch for CommitFest 2009-09