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.
