Re: DROP TABLE... CASCADE weirdness

On Sat, 2002-09-14 at 05:17, Tom Lane wrote:
> 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
> 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.

This seems to be a problem that is of similar nature to our UNIQUE
constraints not working in all cases (depending on the _physical_ order
of tuples, which should never affect any user-visible behaviour).

The two DROP TABLE cases are not equivalent in the sense that the first
is _one_ command and the other is _two_ separate commands.

OTOH, I don't think that fixing DROP TABLE is as urgent as the UNIQUE
because* the UNIQUE bug can come to haunt as at random times* DROP TABLE is usually done by more qualified people
(DBAsand programmers)* our whole inheritance stuff is still somewhat a moving target.
 

-------------
Hannu