Re: [HACKERS] DROP TABLE inside transaction block

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 respect to recovery. These oper-
ations are performed by one or more compilation units and <module>s
or by the direct invocation of SQL.

It is implementation-defined whether or not the non-dynamic or
^^^^^^^^^^^^^^^^^^^^^^
dynamic execution of an SQL-data statement or the execution of
an <SQL dynamic data statement> is permitted to occur within the
same SQL-transaction as the non-dynamic or dynamic execution of
an SQL-schema statement. If it does occur, then the effect on any
^^^^^^^^^^^^^^^^^^^^
open cursor, prepared dynamic statement, or deferred constraint
is implementation-defined. There may be additional implementation-
defined restrictions, requirements, and conditions. If any such
restrictions, requirements, or conditions are violated, then an
implementation-defined exception condition or a completion con-
dition warning with an implementation-defined subclass code is
raised.

Vadim