So, I understood from all those opinions that much of the work is to be done
in the interface language interpreter not postgresql code itself. Am I right
or I missed something?
Regards
Islam Hegazy
----- Original Message -----
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
To: "Florian G. Pflug" <[EMAIL PROTECTED]>
Cc: "Gregory Stark" <[EMAIL PROTECTED]>; "Richard Huxton"
<dev@archonet.com>; "Heikki Linnakangas" <[EMAIL PROTECTED]>; "Tom
Lane" <[EMAIL PROTECTED]>; "Neil Conway" <[EMAIL PROTECTED]>; "Martijn van
Oosterhout" <kleptog@svana.org>; "Islam Hegazy" <[EMAIL PROTECTED]>;
<pgsql-hackers@postgresql.org>
Sent: Monday, March 19, 2007 12:18 PM
Subject: Re: [HACKERS] modifying the tbale function
Florian G. Pflug wrote:
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?
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 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
