From: | Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: inherit support for foreign tables |
Date: | 2014-02-19 07:17:05 |
Message-ID: | CAEZqfEfcsLP+tToNRZxLPg4Ry2ViH28Zm6Kh6AYCqnCz8w2Zmg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Horiguchi-san,
2014-02-18 19:29 GMT+09:00 Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>:
> Could you guess any use cases in which we are happy with ALTER
> TABLE's inheritance tree walking? IMHO, ALTER FOREIGN TABLE
> always comes with some changes of the data source so implicitly
> invoking of such commands should be defaultly turned off.
Imagine a case that foreign data source have attributes (A, B, C, D)
but foreign tables and their parent ware defined as (A, B, C). If
user wants to use D as well, ALTER TABLE parent ADD COLUMN D type
would be useful (rather necessary?) to keep consistency.
Changing data type from compatible one (i.e., int to numeric,
varchar(n) to text), adding CHECK/NOT NULL constraint would be also
possible.
--
Shigeru HANADA
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-02-19 08:40:14 | Re: Is anyone aware of data loss causing MultiXact bugs in 9.3.2? |
Previous Message | Amit Kapila | 2014-02-19 07:11:52 | Re: Patch: show relation and tuple infos of a lock to acquire |