Re: DROP TABLE... CASCADE weirdness - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP TABLE... CASCADE weirdness
Date
Msg-id 23167.1031973479@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP TABLE... CASCADE weirdness  (Alvaro Herrera <alvherre@atentus.com>)
Responses Re: DROP TABLE... CASCADE weirdness  (Hannu Krosing <hannu@tm.ee>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: make installcheck in contrib
Next
From: Joe Conway
Date:
Subject: Re: make installcheck in contrib