Re: DROP TABLE... CASCADE weirdness

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

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
(DBAs and programmers)
* our whole inheritance stuff is still somewhat a moving target.

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