Re: modifying the tbale function

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" <andrew@dunslane.net>
To: "Florian G. Pflug" <fgp@phlo.org>
Cc: "Gregory Stark" <stark@enterprisedb.com>; "Richard Huxton"
<dev@archonet.com>; "Heikki Linnakangas" <heikki@enterprisedb.com>; "Tom
Lane" <tgl@sss.pgh.pa.us>; "Neil Conway" <neilc@samurai.com>; "Martijn van
Oosterhout" <kleptog@svana.org>; "Islam Hegazy" <islheg@hotmail.com>;
<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
>
>
>
>