Bruce Momjian wrote:
>
> > > renaming at abort time has to be done in the right order relative to
> > > dropping tables created during the xact, or else BEGIN; DROP TABLE foo;
> > > CREATE TABLE foo; ABORT won't work right. Currently, an attempt to
> > > lock a table always involves making a relcache entry first, and the
> > > relcache will try to open the underlying files as soon as you do that,
> > > so other backends trying to touch the dying table for the first time
> > > would get unexpected error messages. Probably a few other things.
> > >
> > > In short, a lot of work for a very marginal feature. How many other
> > > DBMSes permit DROP TABLE to be rolled back? How many users care?
> >
> > Oracle auto-commits current in-progress transaction before
> > execution of any DDL statement and executes such statements in
> > separate transaction.
>
> That's cheating!
Maybe :))
But sql3-12aug93 says:
4.41 SQL-transactions
An SQL-transaction (transaction) is a sequence of executions of SQL-statements that is atomic with
respectto recovery. These oper- ations are performed by one or more compilation units and <module>s or by
thedirect invocation of SQL.
It is implementation-defined whether or not the non-dynamic or ^^^^^^^^^^^^^^^^^^^^^^
dynamicexecution of an SQL-data statement or the execution of an <SQL dynamic data statement> is permitted to
occurwithin the same SQL-transaction as the non-dynamic or dynamic execution of an SQL-schema statement.
Ifit does occur, then the effect on any ^^^^^^^^^^^^^^^^^^^^ open cursor, prepared dynamic statement,
ordeferred constraint is implementation-defined. There may be additional implementation- defined
restrictions,requirements, and conditions. If any such restrictions, requirements, or conditions are violated,
thenan implementation-defined exception condition or a completion con- dition warning with an
implementation-definedsubclass code is raised.
Vadim