Re: inherit support for foreign tables
От | Tom Lane |
---|---|
Тема | Re: inherit support for foreign tables |
Дата | |
Msg-id | 12432.1384406906@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | inherit support for foreign tables (Shigeru Hanada <shigeru.hanada@gmail.com>) |
Ответы |
Re: inherit support for foreign tables
|
Список | pgsql-hackers |
Shigeru Hanada <shigeru.hanada@gmail.com> writes: > I'd like to propose adding inheritance support for foriegn tables. > David Fetter mentioned this feature last July, but it seems stalled. > http://www.postgresql.org/message-id/20130719005601.GA5760@fetter.org The discussion there pointed out that not enough consideration had been given to interactions with other commands. I'm not really satisfied with your analysis here. In particular: > 2) Allow foreign tables to have CHECK constraints > Like NOT NULL, I think we don't need to enforce the check duroing > INSERT/UPDATE against foreign table. Really? It's one thing to say that somebody who adds a CHECK constraint to a foreign table is responsible to make sure that the foreign data will satisfy the constraint. It feels like a different thing to say that ALTER TABLE ADD CONSTRAINT applied to a parent table will silently assume that some child table that happens to be foreign doesn't need any enforcement. Perhaps more to the point, inheritance trees are the main place where the planner depends on the assumption that CHECK constraints represent reality. Are we really prepared to say that it's the user's fault if the planner generates an incorrect plan on the strength of a CHECK constraint that's not actually satisfied by the foreign data? If so, that had better be documented by this patch. But for a project that refuses to let people create a local CHECK or FOREIGN KEY constraint without mechanically checking it, it seems pretty darn weird to be so laissez-faire about constraints on foreign data. regards, tom lane
В списке pgsql-hackers по дате отправления: