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