Tom Lane wrote:
>From where?
>
>Minimum respect for the time of your fellow hackers would suggest
>including a gdb traceback in questions like this.
>
>
My apologies. I'll do that next time. I was on a win32 system and the
gdb that comes with the MinGW environment just doesn't do it for me (if
anyone out there knows how to make the MinGW gdb work I'd very much
appreciate any advice). I have a Linux box too though, so that's no excuse.
Anyway, I think I've narrowed the problem down a bit. And indeed, I
think there is a somewhat serious limitation in the SPI layer. Here's
what happens:
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.
3. The SPI_cursor_fetch call in my outer function now fails with
"improper call to spi_printtup" since it is asociated with the first
SPI_connect and since the second SPI_connect has not reached it's
matching SPI_finish yet.
I onclude that with the current implementation there's no way of
achiving data "streaming" using SPI. When I say streaming, I mean a
SETOF function that, one row at a time, delivers the result that it
reads from a SPI_cursor. No matter what I do, short of building the
whole set in memory, will result in unbalanced SPI_connect/SPI_finish
calls. With reservations for me missing something painfully obvious of
course.
Regards,
Thomas Hallgren