Re: SRF in SFRM_ValuePerCall mode

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: "dv (at) nabble" <dvnabble(at)gmail(dot)com>, "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SRF in SFRM_ValuePerCall mode
Date: 2008-04-28 14:07:20
Message-ID: 11972.1209391640@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> dv @ nabble wrote:
>> I am working on implementation of custom "C" SRF for our team. The SRF uses
>> SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall
>> mode
>> all the rows returned from SRF are "materialized" (for performing JOINs,
>> for
>> example).

> Yep, they are unfortunately always materialized. Back when set returning
> functions were implemented, the original patch did actually support true
> "value per call" mode, where the whole result set was not materialized.
> However, it was dropped because of some issues I can't remember off the
> top of my head. The value-per-call API was committed, so that it was
> already in place when someone gets around to implement the backend
> support for it.

That's a rather revisionist view of history ;-) Value-per-call mode has
always been there, just not in nodeFunctionscan.c.

If you're not joining to the function result, and you don't need the
ability to determine its result type on the fly, you could declare it
as returning a specific rowtype and then call it in the targetlist:

select vpc();

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2008-04-28 14:21:08 Re: we don't have a bugzilla
Previous Message Magnus Hagander 2008-04-28 14:00:34 Re: pgstat SRF?