Re: Should this require CASCADE?

Groff, Dana wrote:
> I think that we are getting into two or three issues here.  If I may:
> 
>     (1) Is DROP TABLE <foo> acceptable by the standard?
>     (2) Should we break "old" functionality?
>     (3) assuming we support the old syntax: 
>         should DROP TABLE <foo> be functionally the same as 
>         DROP TABLE <foo> RESTRICT
>     (4) does that mean that That a DROP TABLE <foo> RESTRICT fails on
> foreign key reference to foo.
> 
> Answers from my experience and from my reading of the standard.  (See earlier
> note, I encourage you to determine if I am mistaken, the stand is often hard to
> read.)
> 
>     (1) It is ONLY acceptable (see conformance note) if you do not support
> CASCADE.  If you support CASCADE, you must indicate CASCADE or RESTRICT.  This
> isn't an "optional parameter".  So, no -- the suggestion that "DROP TABLE <foo>"
> is now valid syntax given the CASCADE functionality breaks the standard.
> Vendors <sarcasm> occasionally </sarcasm> decide to break the standard.
> (currently the standards node seems to be down -- I was going to verify that
> nothing in 2004 has yet to change this syntax.  That verification will have to
> come tomorrow (assuming it comes back up).)

Hard to argue why we should invalidate all preexisting SQL books by
rejecting DROP TABLE tab.  If I create a table, and then want to drop
it, why should I have to put another noise word in there to make the
server happy.  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.

Hard to imagine what the standards people were thinking on this one.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026