Hello,
At Fri, 21 Feb 2014 16:33:32 +0900, Etsuro Fujita wrote
> (2014/02/21 15:23), Kyotaro HORIGUCHI wrote:
> >>>> NOTICE: Child foregn table child01 is affected.
> >>>> NOTICE: Child foregn table child02 is affected
> >>>> NOTICE: Child foregn table child03 rejected 'alter tempmin set
> >>>> default'
> > It says that child03 had no ability to perform the requested
> > action, in this case setting a default value. It might be better
> > to reject ALTER on the parent as a whole when any children
> > doesn't accept any action.
>
> Now understood, thougn I'm not sure it's worth implementing such a
> checking mechanism in the recursive altering operation...
Did you mean foreign tables can sometimes silently ignore ALTER
actions which it can't perform? It will cause inconsistency which
operators didn't anticipate. This example uses "add column" for
perspicuitly but all types of action could result like this.
==============
=# ALTER TABLE parent ADD COLUMN x integer;
ALTER TABLE
=# \d parent
Table "public.parent"
Column | Type | Modifiers
--------+---------+--------------------
a | integer |
b | integer |
x | integer |
Number of child tables: 2 (Use \d+ to list them.)
=# \d child1
Foreign table "public.child1"
Column | Type | Modifiers | FDW Options
----------+---------+-----------+-------------
a | integer |
b | integer |
=# (Op: Ouch!)
==============
I think this should result as,
==============
=# ALTER TABLE parent ADD COLUMN x integer;
ERROR: Foreign child table child1 could not perform some of the actions.
=#
==============
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
