Thread: SRF in C

SRF in C

From

Jeff Davis

Date:

11 January 2004, 21:59:49

in section _37.7.1.2. RETURN NEXT_ of the docs, it says that "PL/pgSQL
stores the entire result set before returning from the function".

Is the same true for C, and if so, should we document it in
_33.7.9. Returning Sets from C-Language Functions_ ?

It could be important if someone wanted to return a huge amount of data
from an SRF and it was larger than available RAM.

Regards,
    Jeff Davis

Re: SRF in C

From

Bruce Momjian

Date:

16 January 2004, 19:51:32

Jeff Davis wrote:
> in section _37.7.1.2. RETURN NEXT_ of the docs, it says that "PL/pgSQL
> stores the entire result set before returning from the function".
>
> Is the same true for C, and if so, should we document it in
> _33.7.9. Returning Sets from C-Language Functions_ ?
>
> It could be important if someone wanted to return a huge amount of data
> from an SRF and it was larger than available RAM.

I would assume the C function guys would know this was obvious.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: SRF in C

From

Joe Conway

Date:

16 January 2004, 21:41:14

Bruce Momjian wrote:
> Jeff Davis wrote:
>>in section _37.7.1.2. RETURN NEXT_ of the docs, it says that "PL/pgSQL
>>stores the entire result set before returning from the function".
>>
>>Is the same true for C, and if so, should we document it in
>>_33.7.9. Returning Sets from C-Language Functions_ ?
>>
>>It could be important if someone wanted to return a huge amount of data
>>from an SRF and it was larger than available RAM.
>
> I would assume the C function guys would know this was obvious.

Actually, the situation is a bit more complicated. The section Jeff is
referring to is the one-row-at-a-time (SFRM_ValuePerCall) api that in
theory should not have to suffer from the mentioned limitation in
PL/pgSQL (which uses SFRM_Materialize).

However, the one-row-at-a-time ends up being accumulated into a
tuplestore by ExecMakeTableFunctionResult() anyway, effectively making
SFRM_ValuePerCall look just like SFRM_Materialize, so the memeory
efficiency benefit from SFRM_ValuePerCall is lost :-(

We had talked about supporting both modes, and it has always been on my
long-term personal TODO to go back and address this. But since the
release of 7.3 I have yet to hear a single real life case where the
current SFRM_Materialize mode has been a problem, so fixing this has
stayed low on my list.

Joe