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? http://archives.postgresql.org
