Re: drop table <name> cascade|restrict

From: Date: Mon, 01 Nov 2004 20:21:46 +0000
Subject: Re: drop table <name> cascade|restrict
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-34189@lists.php.net to get a copy of this message
Daniel Convissor wrote:
Hey Lukas: Wondering what you think about the following... FrontBase (and the SQL 99 standard) requires DROP TABLE statements (and DROP SCHEMA, among others) to contain a scope (or whatever it's called) at the end. The sope is either CASCADE or RESTRICT. No other DBMS requires it. I don't know which allow it, but I'll check. So, for now, I've been tweaking tests manually, to check the phptype and then adding the scope to the end as needed. I'm thinking it might be helpful for users if we added a step to fbsql's modify query method that would check for drop table statements that didn't have the scope and then add it if it wasn't there. The default would add RESTRICT, which is apparently more widely accepted and less likely to cause havoc on a database. An option via setOption() will allow the choice to be CASCADE for those that demand it. Considering that anyone using DB with FrontBase already has put the cascade/restrict in all drop table statements that don't have it because FB rejects queries without it. So, this modification won't cause them problems and will help unsupsecting users who try switching from some other DBMS to FrontBase.
I asked Frank Kromann about this and this is his reply: "Setting the default to 'restrict' will give an error when you drop a table with forign key references from other tables, and having the driver add stuff to the SQL statements also sounds a bit wrong to me. If you had a dropTable() method it would be easy to have an extra parameter to handle the restrict|cascade problem." regards, Lukas

« previous php.pear.dev (#34189) next »