| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
| Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "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> |
| Subject: | Re: modifying the tbale function |
| Date: | 2007-03-19 19:35:14 |
| Message-ID: | 87odmphvrh.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> 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...
Yes it would. Consider what happens if the PL function calls into SPI to
execute a query....
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2007-03-19 21:25:13 | Re: Buildfarm feature request: some way to track/classify failures |
| Previous Message | Joe Conway | 2007-03-19 19:23:22 | Re: modifying the tbale function |