Re: DROP TABLE... CASCADE weirdness

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)atentus(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: DROP TABLE... CASCADE weirdness
Date: 2002-09-14 03:17:59
Message-ID: 23167.1031973479@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-09-14 03:27:32 Re: make installcheck in contrib
Previous Message Tom Lane 2002-09-14 03:07:57 Re: make installcheck in contrib