Re: [HACKERS] DROP TABLE inside transaction block

From: Leon <leon(at)udmnet(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-06 16:02:07
Message-ID: 37D3E57F.DE45A85E@udmnet.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

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

Don't know. But here is the idea: drop table rollback is needed in
automation of DB restructuring. There is no need of that in web or
'custom' applications for that feature. It is only needed in complex,
two-stage applications, when first stage manages the underlying DB
structure for the second. In other words, in big projects. If you
are not very ambitious, you can get rid of that complication. I
personally can live without it, though with some redesign of my
project, and there will be no restructuring 'on the fly'.

> > I personally have a project in development which extensively uses
> > that feature. It is meant to be database restructuring 'on the fly'.
>
> What do you mean by "that feature"? The ability to abort a DROP TABLE?
> We have no such feature, and never have.

Sadly I always supposed that rollback can work wonders and resurrect
a table killed in transaction. I was so sure it was so that no testing
had been done. It isn't mentioned in docs.

--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Evan Simpson 1999-09-06 17:10:15 Re: [HACKERS] DROP TABLE inside transaction block
Previous Message Tom Lane 1999-09-06 15:05:48 Re: [HACKERS] PostgreSQL 6.5.1: libpq++ libraries on IRIX 6.5