Re: patch: SQL/MED(FDW) DDL

On Fri, Sep 17, 2010 at 7:47 PM, SAKAMOTO Masahiko
<sakamoto(dot)masahiko(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> Thanks for your comment. I've updated the patches.

I reviewed fdw_table20100917.patch.gz. It adds FOREIGN TABLE in the
SQL standard,
including CREATE/ALTER/DROP FOREIGN TABLE, information_schema (foreign_table
and foreign_table_options), and permission controls. But SELECT from
foreign tables
is not supported yet -- so, SELECT permission won't work in anyway.

In addition to the standard, it also supports some additional operations.
* COMMENT ON FOREIGN TABLE
* WITH OIDS -- reasonable because it is just same as adding a column.
* RULE and DEFAULT -- useful to define updatable foreign table.
* INHERIT, NOT NULL, and CHECK -- they will be used by inter-server
partitioning in the future.

DEFAULT is not used by INSERT INTO foreign table (not supported),
but is used by INSERT RULE. So, it's reasonable for us to have the feature.
Foreign tables are read-only in the standard just like a VIEW.

>> * Needs an error check to SELECT FROM foreign table.
>Fixed. I've added relkind check in set_plain_rel_pathlist(),

Not that if we create a foreign table inherits a normal table, we cannot
SELECT FROM the normal table because planner expands a query to retrieve
data from the foreign table, and the query fails with an error.
ERROR: foreign table scan not implemented.
But I think it's an acceptable limitation for now.

I found some trivial mistakes in the patch:

* src/bin/psql/describe.c : listForeignTables()
+ if (pset.sversion < 80500)
We are in 90100 now ;-)

* SGML doc for CREATE FOREIGN TABLE contains "xxx (integer)".
Is it a typo? All of the Storage Parameters section will be removed.

* SGML doc for DROP FOREIGN TABLE has "a<productname>PostgreSQL</>"
A separator is required between a and <productname>.

For the documentation, we could rewrite some duplicated descriptions
in CREATE/ALTER FOREIGN TABLE into links to CREATE/ALTER TABLE.
They have many copy-and-pasted texts. Do we need to adjust them?

Overall, I think the FOREIGN TABLE DDL part is almost ready to commit if we
accept the proposal itself. Of course we need more discussions about FDW
Routines, but it must be developed based on the infrastructure.

--
Itagaki Takahiro