> From: Shigeru Hanada [mailto:shigeru.hanada@gmail.com]
> 2014-02-10 21:00 GMT+09:00 Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>:
> > (2014/02/07 21:31), Etsuro Fujita wrote:
> >> So, I've modified the patch so
> >> that we continue to disallow SET STORAGE on a foreign table *in the
> >> same manner as before*, but, as your patch does, allow it on an
> >> inheritance hierarchy that contains foreign tables, with the
> >> semantics that we quietly ignore the foreign tables and apply the
> >> operation to the plain tables, by modifying the ALTER TABLE simple
> recursion mechanism.
> >> Attached is the updated version of the patch.
>
> I'm not sure that allowing ALTER TABLE against parent table affects
> descendants even some of them are foreign table. I think the rule should
> be simple enough to understand for users, of course it should be also
> consistent and have backward compatibility.
Yeah, the understandability is important. But I think the flexibility is also important. In other words, I think it
isa bit too inflexible that we disallow e.g., SET STORAGE to be set on an inheritance tree that contains foreign
table(s)because we disallow SET STORAGE to be set on foreign tables directly.
> If foreign table can be modified through inheritance tree, this kind of
> change can be done.
>
> 1) create foreign table as a child of a ordinary table
> 2) run ALTER TABLE parent, the foreign table is also changed
> 3) remove foreign table from the inheritance tree by ALTER TABLE child NO
> INHERIT parent
> 4) here we can't do same thing as 2), because it is not a child anymore.
>
> So IMO we should determine which ALTER TABLE features are allowed to foreign
> tables, and allow them regardless of the recursivity.
What I think should be newly allowed to be set on foreign tables is
* ADD table_constraint
* DROP CONSTRAINT
* [NO] INHERIT parent_table
Thanks,
Best regards,
Etsuro Fujita
