Re: Should this require CASCADE?

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
>