Hannu Krosing dijo: > Tom Lane kirjutas P, 22.09.2002 kell 18:56:
> > It seems to me that DROP ONLY should set attislocal true on each child > > for which it decrements the inherit count, whether the count reaches > > zero or not. > > Would it then not produce a situation, which can't be reproduced using > just CREATEs ? i.e. same column in bot parent (p2.f1) and child (c.f1) > but _not_ inherited ?? No, you cannot do that. For example, create table p1 (f1 int, f2 int); create table p2 (f1 int, f3 int); create table c () inherits (p1, p2); alter table only p1 drop column f1; alter table only p2 drop column f1; In this case, f1 is kept on c, and this situation can be recreated as: create table p1 (f2 int); create table p2 (f3 int); create table c (f1 int) inherits (p2, p3); If you drop it on only one parent it is exactly the same. The next question is whether pg_dump knows how to do such things. The answer is that it doesn't know that it must locally define f1 on c if you drop the column on only one parent. Oddly enough, the following create table p (f1 int); create table c (f1 int not null); produces the right behavior in pg_dump, but create table p (f1 int); create table c () inherits (p); alter table c alter f1 set not null; produces exactly the same as the former. I don't know if it's right. > Then there would be no way to move a field from one parent table to > another and still have it as an inherited column in child. You cannot add a column to a table that is inherited by another table that has a column with the same name: inhtest=# alter table p1 add column f1 int; ERROR: ALTER TABLE: column name "f1" already exists in table "c" inhtest=# alter table only p1 add column f1 int; ERROR: Attribute must be added to child tables too inhtest=# IOW: there's no way to "move" a column, unless you drop it in the whole inheritance tree first. Maybe this is a bug, and adding a column that exists in all childs (with the same name and type) should be allowed. > It also seems bogus considering when doing SELECT * FROM p2 -- How > should the select behave regarding c.f1 - there is a field with the same > name and type but not inherited . I don't understand. Suppose table c has column f1. If I select from p2 and it has f1 also, f1 will show up. If p2 doesn't have f1, it won't: the inheritance status of the attribute doesn't matter. > > This would cause the behavior in the above case to be that > > c.f1 stays around after the second drop (but can be dropped with a third > > drop of c.f1 itself). > > What if you have a deeper hierarchy under c - will this make you > traverse them all to drop f1 ? The recursion is always done in steps one level deep. If the column is inherited from somewhere else in the grandchild, it will stay. If not, it will disappear. If you want to drop in more than one level, but not all of them, you will have to drop it locally on each. This seems just natural, doesn't it? -- Alvaro Herrera (<alvherre[a]atentus.com>) "Granting software the freedom to evolve guarantees only different results, not better ones." (Zygo Blaxell) ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
