Re: DROP TABLE... CASCADE weirdness

Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> Tom Lane dijo:
>> Alvaro Herrera <alvherre(at)atentus(dot)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
to
DROP 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