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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
