Re: Dropping columns with inheritance not working as documented
От | Tom Lane |
---|---|
Тема | Re: Dropping columns with inheritance not working as documented |
Дата | |
Msg-id | 7169.1433283490@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Dropping columns with inheritance not working as documented (Keith Fiske <keith@omniti.com>) |
Ответы |
Re: Dropping columns with inheritance not working as documented
|
Список | pgsql-bugs |
Keith Fiske <keith@omniti.com> writes: > According to the documentation, dropping a column should be propagated down > to all children. This only seems to happen for columns that are added AFTER > a child table is inherited. There's no way to tell when a column was added > to an inheritance set, so this could be very confusing for someone down the > line that wasn't there when a table was set up. I think you might be misreading the docs. DROP COLUMN only propagates to columns that have no independent reason to exist in the child. For instance, given create table p (f1 int); these two commands have different results: create table c () inherits (p); create table c (f1 int) inherits (p); In the second case, c.f1 has two reasons to exist: it was declared locally to c, and it was inherited from p. Dropping p's f1 would remove only one of those reasons to exist, so c.f1 would still be there. If you do something like create table c (f1 int); alter table c inherit p; that's treated as the second case. This is a debatable call but that's the way we decided it should work back when these commands were implemented. FYI, the pg_attribute columns attislocal and attinhcount track the state necessary to implement this behavior. regards, tom lane
В списке pgsql-bugs по дате отправления: