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