By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,710 Members | 1,906 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,710 IT Pros & Developers. It's quick & easy.

SRF in C

P: n/a
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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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
pg***@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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 22 '05 #2

P: n/a
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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 22 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.