Re: Should this require CASCADE?

On Wed, 2002-07-10 at 18:33, Tom Lane wrote:
> Consider
> 
>     CREATE TABLE foo (f1 int primary key);
> 
>     CREATE TABLE bar (f1 int references foo);
> 
>     DROP TABLE foo RESTRICT;

> Our historical behavior is to allow the drop, while issuing a notice
> about implicit deletion of triggers.  But I think SQL92 intends that
> CASCADE should be required.

I think you know my answer (Fail).

- As stated, spec intends it to be required
- Number of automated scripts doing drop table is small
- Users will quickly learn the ropes.  They would be surprised if it
cascaded by default.

The question I suppose is:

DROP TABLE foo;

Does it default to restrict or cascade?  Currently it is restrict.  I
don't believe the spec allows those statements to be without the
qualifier.


Or, how about ALTER TABLE bar DROP CONSTRAINT <fkey_cons> RESTRICT;

I forget what happens here -- does bar depend on foo via the fkey?


ALTER TABLE foo DROP CONSTRAINT <primary key> RESTRICT; should
definitely fail (bar depends on fkey which depends on foo.pkey).