Re: DROP TABLE... CASCADE weirdness

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: DROP TABLE... CASCADE weirdness
Дата
Msg-id 23167.1031973479@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: DROP TABLE... CASCADE weirdness  (Alvaro Herrera <alvherre@atentus.com>)
Ответы Re: DROP TABLE... CASCADE weirdness  (Hannu Krosing <hannu@tm.ee>)
Список pgsql-hackers
Alvaro Herrera <alvherre@atentus.com> writes:
> 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.

I believe that "DROP TABLE a, b CASCADE" is (and should be) equivalent
toDROP TABLE a CASCADE;DROP TABLE b CASCADE;

It would be really hard to make the case that the latter pair of
commands should work in the scenario you give.  Perhaps you should
try to make the case that this equivalence is wrong ... but I don't
much care for that idea either.  If it is wrong, exactly how will
you define the command to work instead?

> My solution would be first to fetch the whole list of OIDs to be dropped
> and only then do the deletion.

I don't think that will get you anywhere in terms of avoiding failures;
you'd still find yourself trying to drop already-dropped tables, only by
OID instead of name.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

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