Re: error-free disabling of individual child partition

On Wed, 2006-05-24 at 09:40 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Wed, 2006-05-24 at 11:17 +0300, Hannu Krosing wrote:
> >> Why "never set back again" ? I'd guess that it should be set back to
> >> true when it is not an inherited column anymore, that is when its
> >> attinhcount reaches zero.
> 
> > Because you have no record of whether it was created locally or
> > inherited when originally created. And: do you care? Why?
> 
> The invariant is supposed to be that every attribute has attislocal
> true or attinhcount > 0 (or both).  Otherwise it has no justification
> to exist.  I see in the regression database that someone has broken
> this invariant; it looks like LIKE inheritance is misimplemented.
> I'm going to insist on a fix for that ;-)
> 
> I think that the correct behavior for add/drop is:
> 
> * ADD INHERITS increments attinhcount for every column found to match
> a column of the parent.  Nothing happens to attislocal.
> 
> * DROP INHERITS decrements attinhcount for every column found to match
> a column of the parent.  Set attislocal true if attinhcount thereby
> goes to zero.
> 
> This makes ADD followed by DROP a certain no-op (if attinhcount was
> zero before the ADD, then attislocal must have been true already).
> However, DROP followed by ADD is not a no-op since we might wind up
> with attislocal true in a column that wasn't that way before.  This
> seems like a relatively minor thing though.  The alternative would
> be to delete the child column when it has no definition sources
> left; which would be self-consistent but I don't think it's the
> behavior we want for this.

Sounds good.

--  Simon Riggs EnterpriseDB          http://www.enterprisedb.com