| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, 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 |
| Subject: | Re: modifying the tbale function |
| Date: | 2007-03-19 19:16:40 |
| Message-ID: | 45FEE198.6030607@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Joe Conway wrote:
> Andrew Dunstan wrote:
>>
>> Are we really sure that this isn't a solution in search of a problem?
>
> The need for value-per-call is real (examples mentioned down-thread)
> and was anticipated from day one of the SRF implementation (in fact
> the first patch I wrote was value-per-call, not materialize). But when
> we realized that value-per-call was not going to work very well for
> any PL *except* C-functions, we switched to SFRM_Materialize as the
> only supported mode, with SFRM_ValuePerCall left as a
> to-be-coded-later option (see SetFunctionReturnMode in execnodes.h).
>
> Personally I think it is worth having SFRM_ValuePerCall even if only C
> functions can make use of it.
>
Yeah, makes plenty of sense for C funcs. I don't think there's an
argument about that. But for that we don't need any threading
infrastructure.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2007-03-19 19:23:22 | Re: modifying the tbale function |
| Previous Message | Joe Conway | 2007-03-19 18:51:00 | Re: modifying the tbale function |