Thomas Hallgren <[EMAIL PROTECTED]> writes:
> 1. I call a function that does an SPI_connect, SPI_prepare,
> SPI_cursor_open, and finally attempts to do an SPI_cursor_fetch.
> 2. Since the SQL statement I'm executing contains a call to function
> returning SETOF, and since that function in turn accesses the database,
> it in turn will issue a SPI_connect in its SRF_IS_FIRSTCALL phase. It
> then returns its first row.
You're right, you can't just return from that inner function while
leaving its SPI connection open.
It might be interesting to redesign SPI around the notion of independent
"connection objects" rather than necessarily having a stack of 'em.
I think that could be made to work ... but not while preserving the
existing SPI API. I'm hesitant to break a ton of user-written code for
a feature that only one person has needed :-(
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
