| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| 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 18:51:00 |
| Message-ID: | 45FEDB94.2030505@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Joe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2007-03-19 19:16:40 | Re: modifying the tbale function |
| Previous Message | Islam Hegazy | 2007-03-19 18:43:43 | Re: modifying the tbale function |