2010/9/15 Heikki Linnakangas <heikki.linnakan...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
