Re: SQL/MED estimated time of arrival?
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Shigeru HANADA <hanada@metrosystems.co.jp>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Hitoshi Harada <umi.tanuki@gmail.com>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, Eric Davies <eric@barrodale.com>, pgsql-hackers@postgresql.org
Date: 2010-11-23T18:18:48Z
Lists: pgsql-hackers
On 23.11.2010 14:22, Shigeru HANADA wrote: > On Tue, 23 Nov 2010 12:30:52 +0200 > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> wrote: >> The docs need some work. The CREATE FOREIGN TABLE reference page seems >> to be copy-pasted from CREATE TABLE, because it talks about constraints >> and WITH/WITHOUT OIDS which surely don't apply to foreign tables. > > Thanks for the comments. > > The page you pointed has been edited for foreign table. In current > design, OID system column and CHECK constraints are supported. Oh, ok. > OID is supported to get oid from the source table (yes, it works only > for postgresql_fdw but it seems useful to support). I don't think that's worthwhile. Oids on user tables is a legacy feature, not recommended for new applications. And if you have to access an existing table that uses oids, you can define a regular column for the oid: CREATE FOREIGN TABLE foreigntable (oid oid, data int4) SERVER myserver; > CHECK constraint > is supported to enable constraint exclusion. Hmm, my gut reaction is that that's a premature optimization. But what about DEFAULTs then, surely that doesn't make sense for a foreign table? > I agree that some kind of documents, such as "How to create new FDW", > should be written. A well-documented file FDW implementation goes a long way for that. But a chapter that explains SQL/MED, how to create foreign tables, servers, user mappings etc, and how they behave. That we need. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com