Re: Error handling in plperl and pltcl

Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> Tom Lane wrote:
>> 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 :-(

I don't think we really have any alternative --- certainly not if you
want to continue to regard plperl as a trusted language. I haven't
bothered to develop a test case, but I'm sure it's possible to crash
the backend by exploiting the lack of reasonable error handling in
spi_exec_query.

There's an ancient saying "I can make this code arbitrarily fast ...
if it doesn't have to give the right answer". I think that applies
here. Fast and unsafe is not how the Postgres project customarily
designs things. I'd rather get the semantics right the first time
and then look to optimize later. (I'm sure we can do more to speed
up subtransaction entry/exit than we have so far.)

regards, tom lane