Hello, At Tue, 18 Feb 2014 09:49:23 -0500, Tom Lane wrote > Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes: > > 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. If the > > ALTER'ing the whole familiy is deadfully useful for certain > > cases, it might be explicitly turned on by some syntax added to > > CREATE FOREIGN TABLE or ALTER TABLE. > > > It would looks like following, > > > CREATE FOREIGN TABLE ft1 () INHERITS (pt1 ALLOW_INHERITED_ALTER, pt2); > > > ALTER TABLE INCLUDE FOREIGN CHILDREN parent ADD COLUMN add1 integer; > > Ugh. This adds a lot of logical complication without much real use, > IMO.
Yeah! That's exactry the words I wanted for the expamples. Sorry for bothering you. I also don't see any use case driving us to overcome the extra complexity. > The problems that have been discussed in this thread are that > certain types of ALTER are sensible to apply to foreign tables and > others are not --- so how does a one-size-fits-all switch help that? None, I think. I intended only to display what this ALTER's inheritance walkthrough brings in. > Also, there are some types of ALTER for which recursion to children > *must* occur or things become inconsistent --- ADD COLUMN itself is > an example, and ADD CONSTRAINT is another. It would not be acceptable > for an ALLOW_INHERITED_ALTER switch to suppress that, but if the > switch is leaky then it's even less consistent and harder to explain. Exactly. It is the problem came with allowing to implicit ALTER on foreign children, Shigeru's last message seems to referred to. At Tue, 18 Feb 2014 14:47:51 +0900, Shigeru Hanada wrote > I'm not sure that allowing ALTER TABLE against parent table affects > descendants even some of them are foreign table. Avoiding misunderstandings, my opinion on whether ALTER may applie to foreign chidlren is 'no'. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers