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