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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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