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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Inconsistent casts
Следующее
От: Tom Lane
Дата:
Сообщение: Re: make installcheck in contrib