Re: [HACKERS] DROP TABLE inside transaction block

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Vadim Mikheev <vadim(at)krs(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Leon <leon(at)udmnet(dot)ru>, Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] DROP TABLE inside transaction block
Date: 1999-09-07 02:53:29
Message-ID: 199909070253.WAA16384@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-09-07 03:00:55 Re: [HACKERS] DROP TABLE inside transaction block
Previous Message Vadim Mikheev 1999-09-07 01:44:19 Re: [HACKERS] DROP TABLE inside transaction block