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