Simon Riggs <[EMAIL PROTECTED]> 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.
You could also imagine clearing attislocal during ADD, but that
just changes which case isn't a complete no-op, so I don't see
any great attraction to it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
