AW: AW: [HACKERS] DROP TABLE inside a transaction block

> > Yes, that was also the general consensus on the list. No statement is
> > ever going to do an implicit commit of previous statements.
>
> I can understand that, but one of these days I hope we can offer the SQL
> semantics of transactions where you don't require a BEGIN.
> (*Optional*,people.) In that case you have to do *something* about
> non-rollbackable DDL (face it, there's always going to be one). Doing what

> Oracle does is certainly not the *worst* one could do. Again, optional.

Imho it *is* the worst one can do.
The only also bad, but acceptable solutions to me would be:

1. disallow this DDL if there is any open DML in this tx,
( allow it, if only select or DDL statements since tx open, and do
the implicit commit)
2. handle this DDL outside any transaction scope even if a tx is open

Implicitly committing previous DML with a DDL statement is imho out of
discussion.

Not in the scope of this discussion is imho the "truncate" command,
since it is 1. not SQL92, 2. per definition a non rollbackable statement
and 3. probably rather a DML statement.

> That still doesn't excuse the current behavior though.

Agreed

Andreas