Thomas Hallgren <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]