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:Dana.Groff@filetek.com]
> Sent: Thursday, July 11, 2002 12:43 PM
> To: 'Tom Lane'; Bruce Momjian
> Cc: pgsql-hackers@postgresql.org
> 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:tgl@sss.pgh.pa.us]
> > Sent: Thursday, July 11, 2002 12:36 PM
> > To: Bruce Momjian
> > Cc: Groff, Dana; Jan Wieck; Stephan Szabo;
> > pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Should this require CASCADE?
> >
> >
> > Bruce Momjian <pgman@candle.pha.pa.us> 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
>
