Added to TODO:
o Add ALTER TABLE tab ADD/DROP INHERITS parent
pg_attribute.attislocal has to be set to 'false' for ADD, and pg_attribute.attinhcount adjusted
appropriately
---------------------------------------------------------------------------
Simon Riggs wrote:
> On Tue, 2006-05-23 at 13:17 -0400, Tom Lane wrote:
> > Simon Riggs <simon@2ndquadrant.com> writes:
> > > - ADD/DROP are opposites; you can use the other one to undo an action
> > > taken in haste, error etc
> >
> > It's not going to be that easy. What exactly will happen to the child
> > table's attislocal/attinhcount settings, and why, during ADD or DROP?
>
> Never is round here ;-)
>
> attislocal: If you set this to False, you wouldn't be able to set it
> back again. If you leave it as it is, you'd never be able to recursively
> drop a column. If you change it, you'll never be able to stop someone
> from dropping a previously defined local column.
> Proposal:
> 1. attislocal is not touched.
> That means if you want to create a new partition you do this:
>
> CREATE TABLE newChild () INHERITS (template);
>
> ... do some processing ...
>
> ALTER TABLE newChild ADD INHERITS parent;
>
> or this:
>
> CREATE TABLE newChild () INHERITS (parent);
> ALTER TABLE newChild DROP INHERITS parent;
>
> ... do some processing ...
>
> ALTER TABLE newChild ADD INHERITS parent;
>
> Neither of which I like.
>
> 2. attislocal is always set False when an appropriate ADD INHERITS is
> actioned. Not ever set back again.
>
> attinhcount changes as appropriate - up for ADDs and down for DROPs.
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
-- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
