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 23275.1100976524@sss.pgh.pa.us
Whole thread Raw
In response to Re: Error handling in plperl and pltcl  (Thomas Hallgren <thhal@mailblocks.com>)
Responses Re: Error handling in plperl and pltcl  (Greg Stark <gsstark@mit.edu>)
Re: Error handling in plperl and pltcl  (Thomas Hallgren <thhal@mailblocks.com>)
List pgsql-hackers
Thomas Hallgren <thhal@mailblocks.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


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pgxs regression
Next
From: Tom Lane
Date:
Subject: Re: pgxs regression