[ redirected to -hackers, where it's actually on topic ]
Matt Miller <mattm@epx.com> writes:
> [redirected from -patches]
> On Wed, 2005-08-03 at 16:25 -0400, Tom Lane wrote:
>> This fundamentally breaks the entire backend. You do not have the
>> option to continue processing after elog(ERROR);
> Okay, I think I'm beginning to see the naivete of that patch's
> simplistic attempt to decouple backend error handling from transaction
> management. But I still haven't found a way to meet my original need:
> On Wed, 2005-08-03 at 19:58 +0000, Matt Miller wrote:
>> The benefit is that [PL/pgSQL] exception
>> handling can be used as a program flow control technique, without
>> invoking transaction management mechanisms. This also adds additional
>> means to enhanced Oracle PL/SQL compatibility.
> 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 and
> without the effect of a rollback. If I catch the exception then
> everything should be fine as far as the transaction is concerned.
The reason you aren't going to be able to manage this in the current
state of plpgsql is that plpgsql doesn't really have any interesting
computational ability "of its own". It 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. So while
you could theoretically make a try/catch construct within plpgsql that
doesn't have subtransaction semantics, there'd basically be no way to
do anything useful within it.
You might take a look at the other PLs such as plperl; those have
behavior much closer to what you are looking for, since their
computational engine is separate from the SQL engine.
regards, tom lane
