Theo Schlossnagle <[EMAIL PROTECTED]> writes: > The select function is dbi-link's remote_select. > remote_select will perform the query and then for each row > return_next which calls the SPI.xs stuff to do plperl_return_next > which is wrapped in a PG_TRY block. I see the value of the try block > to kick back sensible errors to perl, but creating childXids for > every row of a setof seems wildly excessive. What's the harm in > simply not TRY'ing around there?
Failing. The real question is why does the subtransaction actually assign itself an XID --- a simple RETURN NEXT operation ought not do that, AFAICS. What is it you're doing in there that changes the database? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match