Re: patch: SQL/MED(FDW) DDL
От | Heikki Linnakangas |
---|---|
Тема | Re: patch: SQL/MED(FDW) DDL |
Дата | |
Msg-id | 4C906F81.4010108@enterprisedb.com обсуждение исходный текст |
Ответ на | patch: SQL/MED(FDW) DDL (SAKAMOTO Masahiko <sakamoto.masahiko@oss.ntt.co.jp>) |
Ответы |
Re: patch: SQL/MED(FDW) DDL
Re: patch: SQL/MED(FDW) DDL |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: