Re: SQL/MED estimated time of arrival?
От | Heikki Linnakangas |
---|---|
Тема | Re: SQL/MED estimated time of arrival? |
Дата | |
Msg-id | 4CEC0588.1070202@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: SQL/MED estimated time of arrival? (Shigeru HANADA <hanada@metrosystems.co.jp>) |
Ответы |
Re: SQL/MED estimated time of arrival?
|
Список | 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
В списке pgsql-hackers по дате отправления: