Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] DROP TABLE inside a transaction block

From: Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE>
To: Mike Mascari <mascarm(at)mascari(dot)com>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-06 06:59:00
Message-ID: Pine.GSO.4.02A.10003060754300.17581-100000@Svan.DoCS.UU.SE (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, 5 Mar 2000, Mike Mascari wrote:

> 1) Allow DDL statements in transactions. If the transaction
> aborts, currently, corruption can result. Some DDL statements
                     ^^^^^^^^^^^^^^^^^^^^^
I think those are the key words.

> (such as TRUNCATE) make no sense with respect to ROLLBACK. So, I
> guess, the idea is that SOME DDL statements will be ROLLBACK-able
> and some won't - yuck.

I don't see a problem with disallowing some DDL commands in a transaction
as long as they throw an error and the transaction aborts. Users see this
and don't do it next time. Sure it's inconsistent but the current state is
plain bad, sorry.

> 3) Implicitly commit the running transaction and begin a new one.
> Only Vadim and I support this notion, although this is precisely
> what Oracle does (not that that should define PostgreSQL's
> behavior, of course). Everyone else, it seems wants to try to
> implement #1 successfully...(I don't see it happening any time
> soon).

I support that too since it also happens to be SQL's idea more or less.
One of these days we'll have to offer this as an option. At least for
commands for which #1 doesn't work yet.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e(at)gmx(dot)net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-03-06 07:05:52
Subject: Re: [HACKERS] Optimizer badness in 7.0 beta
Previous:From: Alexei ZakharovDate: 2000-03-06 06:06:27
Subject: xlog.c.patch for cygwin port.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group