Re: patch: SQL/MED(FDW) DDL

2010/9/15 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> 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.

I wonder if we might not think of the foreign data wrapper problem as
an instance of an even more general problem. Right now, we have
semi-pluggable index access methods - it's probably not quite possible
to implement one as a standalone module because of XLOG, and maybe
other reasons, but at least there's some abstraction layer there.
Perhaps we should be thinking about a similar facility of table-access
methods. What if someone wants to implement column-oriented storage,
or index-organized tables, or or tables that are really slow under
heavy write loads but can instantaneously compute SELECT COUNT(*) FROM
table, or mauve-colored tables with magic pixie dust? I don't want to
raise the bar for this project to the point where we can never get it
off the ground, but if there's a way to avoid baking in the assumption
that only foreign tables can ever have special capabilities, that
might be valuable.

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