From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Anybody have an Oracle PL/SQL reference at hand? |
Date: | 2004-08-04 04:44:11 |
Message-ID: | Pine.LNX.4.58.0408041440200.25325@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 3 Aug 2004, Tom Lane wrote:
> "Jim C. Nasby" <decibel(at)decibel(dot)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:
EXCEPTION
WHEN 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
From | Date | Subject | |
---|---|---|---|
Next Message | markir | 2004-08-04 04:46:02 | Re: Preliminary PITR documentation available |
Previous Message | Tom Lane | 2004-08-04 04:30:42 | Re: Open items |