RE: JDBC Drop/Create problem?
От | Joachim Achtzehnter |
---|---|
Тема | RE: JDBC Drop/Create problem? |
Дата | |
Msg-id | Pine.LNX.4.21.0012081017420.12933-100000@penguin.kraut.ca обсуждение исходный текст |
Ответ на | RE: JDBC Drop/Create problem? (Peter Mount <petermount@maidstone.gov.uk>) |
Список | pgsql-interfaces |
Today, in a message to Greg Speegle, Peter Mount wrote: > > I'm not sure if the term's "aborted" (been a horrible week, etc), but > as the drop failed, any transaction its contained within must also > fail - thats the point of transactions. Well no, that is not necessarily the point of transactions. It is sufficient to report the error and the calling process can decide whether to continue the transaction using another approach or to abort it by calling rollback. The RDBMS should abort a transaction only when it has no reasonable way to revert to the state before the command that failed. All major RDBMS systems behave this way, hence one cannot be surprised when people expect this behaviour also in Postgresql. This was discussed here several times. > What would be nice would be nested transactions. Then the drop could > be placed within its own transaction, and the outer one wouldn't be > affected. Nested transactions are more general than statement-level abort in that they allow users to define the scope of the nested transaction. It is also the preferred way to cleanly implement statement-level abort. Joachim -- work: joachima@realtimeint.com (http://www.realtimeint.com) private: joachim@kraut.ca (http://www.kraut.ca)
В списке pgsql-interfaces по дате отправления: