Re: DROP COLUMN misbehaviour with multiple inheritance
От | Alvaro Herrera |
---|---|
Тема | Re: DROP COLUMN misbehaviour with multiple inheritance |
Дата | |
Msg-id | Pine.LNX.4.44.0209241925130.3583-100000@David обсуждение исходный текст |
Ответ на | Re: DROP COLUMN misbehaviour with multiple inheritance (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: DROP COLUMN misbehaviour with multiple inheritance
|
Список | pgsql-hackers |
Hannu Krosing dijo: > On Wed, 2002-09-25 at 04:13, Tom Lane wrote: > > Hannu Krosing <hannu@tm.ee> writes: > > > 1) -------------------------------- > > > create table p1 (f1 int, g1 int); > > > create table p2 (f1 int, h1 int); > > > create table c () inherits(p1, p2); > > > drop column p2.f1; -- this DROP is in fact implicitly ONLY > > > > Surely not? At least, I don't see why it should be thought of that way. > > There's always a difference between DROP and DROP ONLY. > > What will be the difference in the user-visible schema ? If I understand the issue correctly, this is the key point to this discussion. The user will not see a difference in schemas, no matter which way you look at it. But to the system catalogs there are two ways of representing this situation: f1 being defined locally by c (and also inherited from p1) or not (and only inherited from p1). I think the difference is purely phylosophical, and there are no arguments that can convince either party that it is wrong. Anyway, there's always a set of commands that can make the user go from one representation to the other. He just has to be careful and know exactly which way the system will work. Whichever way it works, it should be clearly and carefully documented in the ALTER TABLE reference. -- Alvaro Herrera (<alvherre[a]atentus.com>) "Cuando no hay humildad las personas se degradan" (A. Christie)
В списке pgsql-hackers по дате отправления: