Re: Error handling in plperl and pltcl

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

James Robinson <jlrobins(at)socialserve(dot)com> writes:
> The JDBC interface exposes the savepoint interface, via setSavepoint(),
> releaseSavepoint(), and rollback(Savepoint sp) methods on the
> Connection, and Thomas's design of PL/Java offers the SPI via mapping
> it onto JDBC. Would client-side JDBC also suffer from the same
> potential issue of 'commit a savepoint made by a sub-function'?

No, it's not a problem for client-side JDBC, because that's executing in
a client thread that's not going to have its state affected by telling
the server to roll back some work. The fundamental problem on the
server side is keeping rollback from wiping your execution stack and
local variables out from under you :-(.

> Or is this something SPI-specific?

AFAICS the same problem would occur whether the PL used SPI or not;
certainly bypassing SPI to use the database engine more directly
wouldn't solve it.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-12-03 20:20:48 Buildfarm coverage (was Re: OK, ready for RC1 or Beta6)
Previous Message James Robinson 2004-12-03 19:42:59 Re: Error handling in plperl and pltcl