Tom Lane wrote:
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.From where?
Minimum respect for the time of your fellow hackers would suggest
including a gdb traceback in questions like this.
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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
