On Tue, 2006-05-23 at 11:31 -0400, Tom Lane wrote:
> At that point it seems like it'd read more naturally the other way
> round:
>
> ALTER TABLE childN DROP INHERITS old_parent;
> ALTER TABLE childN ADD INHERITS new_parent;
>
> although I'm not sure if this would create a parser conflict against
> ADD/DROP COLUMN.
Behaviour would be:
- If you DROP INHERITS this simply removes the link to the parent. All
existing columns, constraints etc are retained. You can DROP inheritance
on a table that is itself a parent; its children are unaffected.
- If you ADD INHERITS this will fail if it would do the equivalent of
possibly multiple ADD COLUMNs. You can ADD inheritance onto a table that
is itself a parent; its children are unaffected.
- The table data is not scanned at all for either ADD or DROP INHERITS
- You cannot ADD INHERITS if the table being added as parent is already
one of the inheritance set of the target table (i.e. no loops)
- ADD/DROP are opposites; you can use the other one to undo an action
taken in haste, error etc
- Once DROP INHERITS has committed no changes are propagated down from
parent to former child.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
