The answer from H2 (Jim Melton). When this feature was being voted on, some vendors had "cascade" as a default, others had "restrict". So, the compromise was not to define a default. <grumble grumble>
As such providing a "default" is a vendor extension and compliance simply requires we also support the standard syntax. Dana > -----Original Message----- > From: Groff, Dana [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 11, 2002 12:43 PM > To: 'Tom Lane'; Bruce Momjian > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] Should this require CASCADE? > > > I think that is the proper behavior Tom. > > Also I agree with Bruce that this might be an oversight in > the standard. That > is why standards evolve. As I write this I am also sending a > note to H2 asking > about this very issue. The latest working draft still has > this construct. > > Dana > > > -----Original Message----- > > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, July 11, 2002 12:36 PM > > To: Bruce Momjian > > Cc: Groff, Dana; Jan Wieck; Stephan Szabo; > > [EMAIL PROTECTED] > > Subject: Re: [HACKERS] Should this require CASCADE? > > > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Now, if someone wanted to say CASCADE|RESTRICT was > > > required for DROP _only_ if there is some foreign key > > references to the > > > table, I would be OK with that, but that's not what the > > standard says. > > > > But in fact that is not different from what I propose to > do. Consider > > what such a rule really means: > > * if no dependencies exist for the object, go ahead and delete. > > * if dependencies exist, complain. > > How is that different from "the default behavior is RESTRICT"? > > > > regards, tom lane > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
