Re: AW: [HACKERS] Re: [GENERAL] drop/rename table and transactions

Zeugswetter Andreas SEV wrote:

> Vadim wrote:
> > > The developers appear to want to make them
> > > work (i.e., have the
> > > ability to rollback a DROP TABLE, ALTER TABLE ADD COLUMN,
> > > etc.). This, in my
> > > opinion, goes far above and beyond the call of duty for a
> > >  RDBMS. Oracle issues
> > > an implicit COMMIT whenever a DDL statement is found.
> >
> > And I agreed with this.
>
> And I strongly disagree.
> This sounds like pushing the flush button in the toilet,
> and instead of the toilet flushing you get a shower.
>
> How could anybody come to the idea that a DDL statement
> also does a commit work if inside a transaction ?
>
> Now this sound so absurd, that I even doubt Oracle would do this.
>
> Andreas

I hate to disappoint your faith in Oracle,  but....
(from the Oracle 7 SQL Lanugage Reference Manual):

--------------
Transactions

A transaction (or a logical unit of work) is a sequence of SQL
statements that ORACLE treats as a single unit. A transaction
begins with the first executable SQL statement after a COMMIT,
ROLLBACK or connection to the database. A transaction ends with
a COMMIT, ROLLBACK or disconnection (intentional or unintentional)
from the database. Note that ORACLE issues an implicit COMMIT
before and after any Data Definition Language statement.

You can also use a COMMIT or ROLLBACK statement to terminate
a read only transaction begun by a SET TRANSACTION statement.
--------------

Since ORACLE has 70% of the RDBMS market, it is the de facto
standard that the RDBMS will issue an implicit COMMIT when
processing a DDL statement. Like I said before, I would LOVE to
have working support for ROLLBACKs of DDL statements. But I
would prefer to have implicit COMMITs over corrupted indexes,
tables, and mandatory DBA intervention.

Mike Mascari