Re: [HACKERS] DROP TABLE inside transaction block
От | José Soares |
---|---|
Тема | Re: [HACKERS] DROP TABLE inside transaction block |
Дата | |
Msg-id | 37D50B5C.636B68C2@sferacarta.com обсуждение исходный текст |
Ответ на | DROP TABLE inside transaction block (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] DROP TABLE inside transaction block
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] DROP TABLE inside transaction block (Bruce Momjian <maillist@candle.pha.pa.us>) Re: [HACKERS] DROP TABLE inside transaction block (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
Tom Lane ha scritto: > Pursuant to a phone conversation I had with Bruce, I added code this > morning to reject DROP TABLE or DROP INDEX inside a transaction block; > that is, you can't do BEGIN; DROP TABLE foo; END anymore. The reason > for rejecting this case is that we do the wrong thing if the transaction > is later aborted. Following BEGIN; DROP TABLE foo; ABORT, the system > tables will claim that foo is still valid (since the changes to them > were never committed) but we've already unlinked foo's physical file, > and we can't get it back. Solution: only allow DROP TABLE outside > BEGIN, so that the user can't try to change his mind later. > > However, on second thought I wonder if this cure is worse than the > disease. Will it be unreasonably hard to drop tables using client > interfaces that like to wrap everything in BEGIN/END? Plugging an > obscure hole might not be worth that. > > A possible compromise is not to error out, but just to issue a NOTICE > along the lines of "DROP TABLE is not undoable, so don't even think of > trying to abort now..." > > (Of course, what would be really nice is if it just worked, but I don't > see any way to make that happen without major changes. Simply > postponing the unlink to end of transaction isn't workable; consider > BEGIN; DROP TABLE foo; CREATE TABLE foo; ...) > > Any thoughts? Will there indeed be a problem with JDBC or ODBC if we > leave this error check in place? > > regards, tom lane > > ************ > > ************ Seems a good solution. I have an old note about this problem. What about to reject also the following commands inside transactions? * BUGS: There are some commands that doesn't work properly inside transactions. Users should NOT use the following statements inside transactions: - DROP TABLE -- in case of ROLLBACK only table structure will be recovered,data will be lost. - CREATE VIEWS -- the behavior of the backend is unpredictable. - ALTER TABLE -- the behavior of the backendis unpredictable. - CREATE DATABASE -- in case of ROLLBACK will be removed references from"pg_database" but directory $PGDATA/databasename will not be removed. José
В списке pgsql-hackers по дате отправления:
Следующее
От: Tom LaneДата:
Сообщение: Re: [HACKERS] PostgreSQL 6.5.1: libpq++ libraries on IRIX 6.5