Re: Two features left

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

Responses

Browse pgsql-general by date

  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