Jan!
Thursday, November 28, 2002, 4:24:45 PM, you wrote:
>>TL> "Timur V. Irmatov" <itvthor@sdf.lonestar.org> writes:
>>>> It is very simple to implement (i think) it other way - just do not
>>>> force transaction to enter abort state afer exception.
>>
>>TL> Better study the backend's error handling before you say that.
JW> side-note: I never had a look at this code, but if you want to scare
JW> off people from changing anything there, because it looks too
JW> complicated, it might indicate the need for some refactoring :-)
>>but I still insist that using nested transaction to allow
>>transactions to continue after SQL exceptions is not a good idea..
JW> What is the whole point of having a nested transaction vs. a single
JW> transaction?
I am not argueing against nested transactions.
I'm just trying to say that there should be more natural way of
allowing transactions to continue other than wrapping each command in
separate sub-transaction..
JW> IMHO, if you want to abort all outer transactions when an inner
JW> transaction fails this behaviour would be no different from having
JW> only one transaction for the whole action.
Read what Jon Swinth wrote:
--- begin quote ---
The other feature is to allow transactions to continue without being forced to
rollback when a SQL exception occurs. In many applications, a SQL exception
is handled and an appropriate alternative generated so the transaction goes
on. PostgreSQL does not support this and errors on every call made in the
same transaction before calling rollback. Some people are willing and able
to adjust there application code to handle this. Many people have long
running transactions where this is not easily accomplished or are using a
pre-existing application that they can't change.
--- end quote ---
Sincerely yours,
Timur.
