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"

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to