From: | "Jan Weerts" <j(dot)weerts(at)i-views(dot)de> |
---|---|
To: | "'Timur Irmatov'" <itvthor(at)sdf(dot)lonestar(dot)org>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Two features left |
Date: | 2002-11-28 11:24:45 |
Message-ID: | B349BABAF9A92F4D9FBFCADF8D5FEDD50810C9@ivsrv03.i-views.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi all!
my $0.02 on this, though I am not an expert in DBs at all.
>TL> "Timur V. Irmatov" <itvthor(at)sdf(dot)lonestar(dot)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.
side-note: I never had a look at this code, but if you want to scare
off people from changing anything there, because it looks too
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..
What is the whole point of having a nested transaction vs. a single
transaction?
IMHO, if you want to abort all outer transactions when an inner
transaction fails this behaviour would be no different from having
only one transaction for the whole action.
As already stated the outer transactions can check on the return
status of an inner transaction and decide on, what needs to be done in
cause of its failure.
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Felipe Schnack | 2002-11-28 11:42:21 | cvs |
Previous Message | Erwan DUROSELLE | 2002-11-28 11:19:16 | Rp. : Re: French translation of 7.3 press release |