Hi, Following ALTER TABLE actions are applied recursively to inheritance descendents via ATSimpleRecursion() -
ALTER COLUMN DEFAULT ALTER COLUMN DROP NOT NULL ALTER COLUMN SET NOT NULL ALTER COLUMN SET STATISTICS ALTER COLUMN SET STORAGE The code at the beginning of ATSimpleRecursion() looks like - /* * Propagate to children if desired. Non-table relations never have * children, so no need to search in that case. */ if (recurse && rel->rd_rel->relkind == RELKIND_RELATION) Not sure if it's great idea, but now that foreign tables can also have children, should above be changed to take that into account? Any inheritance related recursion performed without using ATSimpleRecursion() recurse as dictated by RangeVar.inhOpt; so even foreign inheritance parents expand for various ALTER TABLE actions like adding a column though that is not a meaningful operation on foreign tables anyway. An example, postgres=# alter foreign table fparent alter a type char; ALTER FOREIGN TABLE postgres=# select * from fparent; ERROR: attribute "a" of relation "fchild1" does not match parent's type Above error, AIUI, is hit much before it is determined that fparent is a foreign table, whereas the following is FDW-specific (waiting to happen) error, postgres=# alter foreign table fparent add b char; ALTER FOREIGN TABLE postgres=# SELECT * FROM fparent; ERROR: column "b" does not exist CONTEXT: Remote SQL command: SELECT a, b FROM public.parent Not sure if the first case could be considered s a bug as foreign tables are pretty lax in these regards anyway. But if ATSimpleRecursion() prevents errors that result from concepts independent of foreign tables being involved, maybe, we need to fix? Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers