Re: error-free disabling of individual child partition - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: error-free disabling of individual child partition
Date
Msg-id 200605232057.k4NKvTG04393@candle.pha.pa.us
Whole thread Raw
In response to Re: error-free disabling of individual child partition  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
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. +


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: API changes in patch release
Next
From: "Brendan Jurd"
Date:
Subject: SQL compliant interval implementation