Re: SRF in C
От | Joe Conway |
---|---|
Тема | Re: SRF in C |
Дата | |
Msg-id | 4008683B.70504@joeconway.com обсуждение исходный текст |
Ответ на | Re: SRF in C (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: