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).