Re: [HACKERS] DROP TABLE inside a transaction block - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] DROP TABLE inside a transaction block
Date
Msg-id Pine.GSO.4.02A.10003060754300.17581-100000@Svan.DoCS.UU.SE
Whole thread Raw
In response to Re: [HACKERS] DROP TABLE inside a transaction block  (Mike Mascari <mascarm@mascari.com>)
List 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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-hackers by date:

Previous
From: "Alexei Zakharov"
Date:
Subject: xlog.c.patch for cygwin port.
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Optimizer badness in 7.0 beta