RE: [HACKERS] DROP TABLE inside transaction block
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] DROP TABLE inside transaction block |
Дата | |
Msg-id | 000201bef991$3f7bba80$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] DROP TABLE inside transaction block (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane > Sent: Tuesday, September 07, 1999 10:54 PM > To: Jos·Soares > Cc: pgsql-hackers@postgreSQL.org > Subject: Re: [HACKERS] DROP TABLE inside transaction block > > > José Soares <jose@sferacarta.com> writes: > > 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 backend is unpredictable. > > - CREATE DATABASE -- in case of ROLLBACK will be removed references > > from "pg_database" but directory > > $PGDATA/databasename will not be removed. > > CREATE DATABASE (and presumably also DROP DATABASE) probably should > refuse to run inside a transaction. > Probably VACUUM should also refuse to run inside transactions. VACUUM has a phase like commit in the middle of execution. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: