Re: DROP TABLE... CASCADE weirdness
От | Alvaro Herrera |
---|---|
Тема | Re: DROP TABLE... CASCADE weirdness |
Дата | |
Msg-id | Pine.LNX.4.44.0209132258070.28737-100000@cm-lcon1-46-187.cm.vtr.net обсуждение исходный текст |
Ответ на | Re: DROP TABLE... CASCADE weirdness (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: DROP TABLE... CASCADE weirdness
|
Список | pgsql-hackers |
Tom Lane dijo: > Alvaro Herrera <alvherre@atentus.com> writes: > > I understand what's going on and how to get the desired behavior, but > > it's weird and I think it should be fixed if possible. > > Define why you consider this broken On the first case, if I'm specifying to drop both tables, I don't want to be bothered telling me that the second depends on the first: I have already specified that I want it dropped. On the second case (CASCADE), I'm trying to drop the second table, so I do not want to be bothered telling me that it doesn't exist, because that is exactly what I want. > and what you would consider fixed. In both cases (CASCADE and RESTRICT), both tables should be dropped (after all, that's what I'm trying to do). It's only an annoyance, and I suppose it's very difficult to "fix". My solution would be first to fetch the whole list of OIDs to be dropped and only then do the deletion. -- Alvaro Herrera (<alvherre[a]atentus.com>) "Tiene valor aquel que admite que es un cobarde" (Fernandel)
В списке pgsql-hackers по дате отправления: