Just a thought - I believe that there are portable user-space thread
implementations that contain little or no machine-specific code. What

if postgres used one of those to switch from the PL into the executor
and back after, say, 1000 rows were returned by the SFR?

Advertising

What would be needed is basically some enhanced version of setjmp/longjmp
that actually saves the stack, and not just resets the stackpointer.
Since context switching would occur only at two well-defined places
(Some return_next_row function that PLs call when a SFR returns a row,
and in the executor if no more previously returned rows from that SFR
are available), this wouldn't introduce the usual multithreading
headache, but still allow to switch in and out of the PL interpreter.

This just sounds horribly fragile.
Are we really sure that this isn't a solution in search of a problem?
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org