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