Re: Two features left
От | Timur V. Irmatov |
---|---|
Тема | Re: Two features left |
Дата | |
Msg-id | 1405580344.20021128114252@sdf.lonestar.org обсуждение исходный текст |
Ответ на | Re: Two features left (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Two features left
|
Список | pgsql-general |
Tom! Thursday, November 28, 2002, 3:31:18 AM, you wrote: TL> Jon Swinth <jswinth@atomicpc.com> writes: >> Ok, so it looks like your nested transactions and savepoints are really the >> same thing. The question is, are you going to change the way SQL exceptions >> are handled so that simply abort that SQL statement don't require a rollback? >> With your enhancement, it sounds like calling BEGIN before each SQL statement >> could acheive what I am asking for, but the issue is existing applications >> will not expect to have to do so. TL> Au contraire: existing PG applications would be broken completely if the TL> behavior of error rollback suddenly changes. TL> There is also an efficiency issue: nested transactions will not be free, TL> and one should not be forced to pay for them when not needed. It seems to me that it is very BAD idea to solve the problem of the original poster (to allow transactions to continue after SQL exception) by the means of nested transactions. It is very simple to implement (i think) it other way - just do not force transaction to enter abort state afer exception. There will be no performance penalty. I think there could be some variable, like that: SET TOLERANT_TRANSACTIONS TO TRUE; which is FALSE by default for compatibility. I did not looked at the code and I am not a C or DB guru, but I suspect, there is just a simple check: did last statement failed? if so, enter abort state. It requires just another check of TOLERANT_TRANSACTIONS variable, and if it is true, just notiy app and continue to work as nothing has happened... why to boother with nested transactions for this simple feature? TL> It might be reasonable to have a GUC parameter that enables an implicit TL> subtransaction around each command in a transaction block (perhaps only TL> at the topmost nesting level?) --- but it won't become the default TL> behavior in the foreseeable future. this is not required if the desired feature will be implemented "naturally" :) Sincerely yours, Timur.
В списке pgsql-general по дате отправления: