Re: Error handling in plperl and pltcl

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Thomas Hallgren <thhal(at)mailblocks(dot)com>, Brett Schwarz <brett_schwarz(at)Yahoo(dot)com>, Richard Huxton <dev(at)archonet(dot)com>, James William Pye <flaw(at)rhid(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Error handling in plperl and pltcl
Date: 2004-12-03 19:28:06
Message-ID: 737.1102102086@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <JanWieck(at)Yahoo(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2004-12-03 19:32:41 Calling for translation finalization
Previous Message Tom Lane 2004-12-03 19:14:56 Re: OK, ready for RC1 or Beta6