Hi Vladimir, In your example, it seems simple. However consider a more advanced example:
DROP TABLE A, B, C, D, E, F, G; where there is a series of dependencies. Determining the dependencies automatically would be tricky. I think it is reasonable for SQL (and H2's implementation thereof) to demand that you specify the tables to drop in an order that satisfies the dependencies. On Sunday, 25 August 2013 19:58:57 UTC+2, Vladimir Oslon wrote: > > Here's a little SQL excerpt: > CREATE TABLE A (A INT); > CREATE TABLE B (B INT AS SELECT A FROM A); > DROP TABLE A,B; > > running it, I get > Cannot drop "PUBLIC.A" because "PUBLIC.B" depends on it; SQL statement: > DROP TABLE A,B [90107-171] 90107/90107 (Help) > > This could have been predicted - after all, the doc only promises that > "All dependent views are dropped as well if the CASCADE clause is used." > However, DROP SCHEMA and even DROP ALL OBJECTS yield the same result, > although the doc for the latter says "Drops all existing views, tables, > sequences, schemas, function aliases, roles, user-defined aggregate > functions, domains, and users (except the current user)." > > The INFORMATION_SCHEMA only keeps track of the above dependency in > TABLES/COLUMNS (in the SQL form), so I see no reasonable way to drop a > table without going to unreasonable lengths figuring out its dependants. > > Yet a method must exist to force dropping a table (please don't suggest > DROP B,A instead of DROP A,B). > Or have I run into a design flaw? > > Thanks, > Vladimir > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
