(2014/02/20 15:47), Kyotaro HORIGUCHI wrote:
Although my concerns here are only two points,
unanticipated application and "maintenancibility".  I gave a
consideration on these issues again.

Sorry, I misunderstood what you mean by "unanticipated application".

Then, I think it could be enough by giving feedback to operators
for the first issue.

=# ALTER TABLE parent ADD CHECK (tempmin < tempmax),
                       ALTER tempmin SET NOT NULL,
                       ALTER tempmin SET DEFAULT 0;
NOTICE: Child foregn table child01 is affected.
NOTICE: Child foregn table child02 is affected
NOTICE: Child foregn table child03 rejected 'alter tempmin set default'

What do you think about this? It looks a bit too loud for me

I think that's a good idea.  What do others think?

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

We spent a lot of time discussing this issue, and the consensus is
that it's users' fault if there are some tuples on the remote side
violating a given constraint, as mentioned in the documentation.

I'm worried about not that but the changes and possible
inconsistency would take place behind operators' backs. And this
looks to cause such inconsistencies for me.

That is what you mean by "unanticipated application", right?

* [NO] INHERIT parent_table

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

I didn't express clearly.  Sorry for that.  Let me explain about it.

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


Best regards,
Etsuro Fujita

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to