Re: [HACKERS] DROP TABLE inside transaction block

Поиск
Список
Период
Сортировка
От Leon
Тема Re: [HACKERS] DROP TABLE inside transaction block
Дата
Msg-id 37D3E57F.DE45A85E@udmnet.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] DROP TABLE inside transaction block  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] PostgreSQL 6.5.1: libpq++ libraries on IRIX 6.5
Следующее
От: Evan Simpson
Дата:
Сообщение: Re: [HACKERS] DROP TABLE inside transaction block