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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
