Tom Lane wrote:
>Thomas Hallgren <thhal@mailblocks.com> writes:
>
>
>>My approach with PL/Java is a bit different. While each SPI call is
>>using a try/catch they are not using a subtransaction. The catch will
>>however set a flag that will ensure two things:
>>
>>
>
>
>
>>1. No more calls can be made from PL/Java to the postgres backend.
>>2. Once PL/Java returns, the error will be re-thrown.
>>
>>
>
>That's what pltcl has always done, and IMHO it pretty well sucks :-(
>it's neither intuitive nor useful.
>
>
Given that most SPI actions that you do doesn't elog (most of them are
typically read-only), it's far more useful than imposing the overhead of
a subtransaction on all calls. That IMHO, would really suck :-(
Ideally, the behavior should be managed so that if a subtransaction is
started intentionally, crash recovery would be possible and the function
should be able to continue after it has issued a rollback of that
subtransaction.
I'm suprised you say that this is not useful. I've found that in most
cases when you encounter an elog, this is the most intuitive behavior.
Either you don't do any cleanup, i.e. just return and let the elog be
re-thrown, or you close some files, free up some resources or whatever,
then you return. Not many functions would continue executing after an
elog, unless of course, you *intentionally* started a subtransaction.
I'll investigate what's entailed in handling SPI calls performed in a
subtransaction differently so that calls are blocked only until the
subtransaction is rolled back. Since I have my own JDBC driver, that
doesn't sound too hard. I guess PL/Perl and PL/Tcl has something similar
where they could track this.
Such handling, in combination with a "recoverable" status in the elog's
error structure, would create a really nice (end efficient) subsystem.
Regards,
Thomas Hallgren