Re: PL/pgSQL: EXCEPTION NOSAVEPOINT - Mailing list pgsql-hackers

From Matt Miller
Subject Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Date
Msg-id 1125615518.3636.71.camel@dbamm01-linux
Whole thread Raw
In response to Re: PL/pgSQL: EXCEPTION NOSAVEPOINT  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
List pgsql-hackers
On Thu, 2005-09-01 at 18:28 -0400, Tom Lane wrote:
> Matt Miller <mattm@epx.com> writes:
> > Basically I'd like my Pl/pgSQL code to be able to utilize the try/catch
> > paradigm of error handling without the overhead of subtransactions
> 
> [Pl/pgSQL] can't even do 2+2 without 
> calling the main executor --- and recovering from elog(ERROR) without a
> transaction rollback is not part of the executor's contract.

Okay, so that's the crux regarding PL/pgSQL.

> You might take a look at the other PLs such as plperl

That would defeat my goal of not rewriting all my Oracle code.

If I were fool enough to plan an attack on the main executor's exception
handling to try and disarm it of its subtransaction semantics, where
would I start?  Where would I end?  What would I do in between?  Can New
Orleans be rebuilt above sea level?

Seriously, though, I'm willing to devote considerable time to this.
Rewriting all my Oracle code function-by-function could be painful, and
I would end up dragging other people around this company into it.  I'm
still trying to hold on to my fantasy that I can hack Postgres (and
contrib/ora2pg) into submission.  In the end I'm hoping that the move
from Oracle will be made easier for others.


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: ALTER TABLE ( smallinto -> boolean ) ...
Next
From: Tom Lane
Date:
Subject: Re: PL/pgSQL: EXCEPTION NOSAVEPOINT