Re: inherit support for foreign tables

Hello,

At Tue, 18 Feb 2014 19:24:50 +0900, "Etsuro Fujita" wrote
> > From: Shigeru Hanada [mailto:shigeru(dot)hanada(at)gmail(dot)com]
> > 2014-02-10 21:00 GMT+09:00 Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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 is a
> 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.

What use case needs such a flexibility precedes the lost behavior
predictivity of ALTER TABLE and/or code "maintenancibility"(more
ordinally words must be...) ? I don't agree with the idea that
ALTER TABLE implicitly affects foreign children for the reason in
the upthread. Also turning on/off feature implemented as special
syntax seems little hope.

If you still want that, I suppose ALTER FOREIGN TABLE is usable
chainging so as to walk through the inheritance tree and affects
only foreign tables along the way. It can naturally affects
foregin tables with no unanticipated behavor.

Thoughts?

> > 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

As of 9.3

http://www.postgresql.org/docs/9.3/static/sql-alterforeigntable.html

> Consistency with the foreign server is not checked when a
> column is added or removed with ADD COLUMN or DROP COLUMN, a
> NOT NULL constraint is added, or a column type is changed with
> SET DATA TYPE. It is the user's responsibility to ensure that
> the table definition matches the remote side.

So I belive implicit and automatic application of any constraint
on foreign childs are considerably danger.

> * [NO] INHERIT parent_table

Is this usable for inheritance foreign children? NO INHERIT
removes all foreign children but INHERIT is nop.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center