Re: inherit support for foreign tables

Hello,

> > Then the second issue, however I don't have enough idea of how
> > ALTER TABLE works, the complexity would be reduced if acceptance
> > chek for alter "action"s would done on foreign server or data
> > wrapper side, not on the core of ALTER TABLE. It would also be a
> > help to output error messages like above.
>
> I'm not sure it's worth having such an mechanism inside/outside the PG
> core. I might misunderstand your concern here, but is it the risk of
> constraint violation?

A bit different:) It's the problem of how and who decides whether
each ALTER action given can be performed on each child. Set of
available actions vary according to the nature of each foreign
table/server/driver and also according to their functional
evolutions made in future, largely independent of the core,
maybe. The core oughtn't to.. couldn't maintain such a function
judging availability of every possible combination of action and
foreign table.

> If so, I'd like to vote for an idea of avoiding
> that violation by making the FDW in itself perform ExecQual() for each
> tuple retrived from the remote server at the query time.

In my humble opition, it is not so serious problem that
functionally acceptable actions can cause any kind of
inconsistency by the nature of fdw so far. It is well documented
and operators should be aware of such inconsistencies after being
informed of what they did, by the NOTICE messages. I think.

> >> * ALTER FOREIGN TABLE target_table *INHERIT* parent_table: Add the
> >> * target table as a new child of the parent table.
> >> * ALTER FOREIGN TABLE target_table *NO INHERIT* parent_table: Remove the
> >> * target table from the list of children of the parent table.
> >
> > I got it, thank you. It alone seems no probmen but also doesn't
> > seem to be a matter of 'ALTER TABLE'. Could you tell me how this
> > is related to 'ALTER TABLE'?
>
> These are not related to ALTER TABLE. [NO] INHERIT parent_table (and
> ADD/DROP CONSTRAINT) are what I think should be newly allowed to apply
> to foreign tables directly.

Thank you, I understood that. I thought it already existed.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center