Hannu Krosing dijo:
> For me it feels assymmetric (unless we will make attislocal also int
> instead of boolean ;). This assymetric nature will manifest itself when
> we will have ADD COLUMN which can put back the DROP ONLY COLUMN and it
> has to determine weather to remove the COLUMN definition from the child.
Well, the ADD COLUMN thing is something I haven't think about. Let's
see: if I have a child with a local definition of the column I'm adding,
I have to add one to its inhcount, that's clear. But do I have to reset
its attislocal?
> What does the current model do in the following case:
>
> create table p (f1 int, g1 int);
> create table c (f1 int) inherits(p);
> drop column c.f1;
>
> Will it just set attisinh = 1 on c.f1 ?
No, it will forbid you to drop the column. That was the intention on
the first place: if a column is inherited, you shouldn't be allowed to
drop or rename it. You can only do so at the top of the inheritance
tree, either recursively or non-recursively. And when you do it
non-recursively, the first level is marked non-inherited.
> There seem to be actually 3 different possible behaviours for DROP
> COLUMN for hierarchies.
Well, I'm not too eager to discuss this kind of thing: it's possible
that multiple inheritance goes away in a future release, and all these
issues will possibly vanish. But I'm not sure I understand the
implications of "interfaces" (a la Java multiple inheritance).
--
Alvaro Herrera (<alvherre[a]atentus.com>)
"Acepta los honores y aplausos y perderas tu libertad"
