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). ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
