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