Re: Error handling in plperl and pltcl - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Error handling in plperl and pltcl
Date
Msg-id 737.1102102086@sss.pgh.pa.us
Whole thread Raw
In response to Re: Error handling in plperl and pltcl  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Jan Wieck <JanWieck@Yahoo.com> writes:
> Your suggestion to expose a plain savepoint interface to the programmer 
> leads directly to the possiblity to commit a savepoint made by a 
> sub-function in the caller and vice versa - which if I understood Tom 
> correctly is what we need to avoid.

If we expose a savepoint-style interface in the PLs, it'll need to be
restricted to the cases we can actually support.  I don't have a problem
with the idea in the abstract, but there was no time to do it for 8.0.
I think we can add that on in 8.1, or later, without creating any
backwards-compatibility issues compared to where we are now --- at least
not for pltcl and plperl.  (We might regret having tied subtransactions
to exceptions in plpgsql, not sure.)

The real issue is whether the required restrictions would be ugly enough
that savepoint syntax doesn't seem like a nice API.  I thought so when
I did the coding for plpgsql, but I'm less sure at the moment.  You'd
probably have to prototype an implementation to find out for certain.
It might be that the only real restriction is to make savepoint names
local to functions (a/k/a savepoint levels), which wouldn't be bad at
all.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: OK, ready for RC1 or Beta6
Next
From: Peter Eisentraut
Date:
Subject: Calling for translation finalization