Re: [HACKERS] DROP TABLE inside transaction block

Tom Lane wrote:
> 
> There are a bunch of subtleties to be dealt with though.  A couple of
> gotchas I can think of offhand: better flush dirty buffers for the
> target rel before doing the rename, else another backend might try to
> do it between DROP and COMMIT, and write to the wrong file name.  The

BTW, I'm going to use relation oid as relation file name for WAL:
it would be bad to store relname in log records for each updated
tuple and it would be hard to scan pg_class to get relname from
reloid in recovery.

> 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. 

Vadim