On Tue, 3 Aug 2004, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > On Tue, Aug 03, 2004 at 10:17:14AM -0400, Tom Lane wrote:
> >> Right. Essentially, our implementation is supplying the SAVEPOINT and
> >> ROLLBACK TO commands implicitly as part of any block with an EXCEPTION
> >> clause. When we get around to updating the "Oracle porting" guide in
> >> the plpgsql docs, this will need to be clearly explained.
>
> > If it's not difficult it would probably be good to allow for handling
> > the rollback yourself.
>
> We're not doing that. This is a server-side function we're talking
> about: it is executing *inside* the transaction that you want it to fool
> with the status of. If you want logic that can issue SAVEPOINT and
> ROLLBACK at arbitrary points, code it on the client side.
Just another take on this: a lot of PL/SQL I've seen uses the EXCEPTIONs
block simply to output strings describing the exception. That is:
EXCEPTIONWHEN foo THEN RAISE NOTICE 'You cannot foo';WHEN bar THEN RAISE NOTICE 'You cannot bar';
END;
In this case, no exception handler is accessing or modifying SQL data.
Would it be worth trying to identify these situations so that we can avoid
subtransaction overhead?
Gavin
