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

From Leon
Subject Re: [HACKERS] DROP TABLE inside transaction block
Date
Msg-id 37D3E57F.DE45A85E@udmnet.ru
Whole thread Raw
In response to Re: [HACKERS] DROP TABLE inside transaction block  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] PostgreSQL 6.5.1: libpq++ libraries on IRIX 6.5
Next
From: Evan Simpson
Date:
Subject: Re: [HACKERS] DROP TABLE inside transaction block