Re: modifying the tbale function

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 19:23:22
Message-ID: 45FEE32A.3010804@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan wrote:
> 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.

Oh sure -- sorry I wasn't clear. I wasn't trying to support the idea of
threading so much as the idea that value-per-call itself has merit for a
number of use cases.

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-03-19 19:35:14 Re: modifying the tbale function
Previous Message Andrew Dunstan 2007-03-19 19:16:40 Re: modifying the tbale function