On 06/15/19 21:46, Chapman Flack wrote: > On 06/15/19 21:21, Tom Lane wrote: >> Yup. (Of course, you don't have to use the SRF_FIRSTCALL_INIT >> infrastructure.) > > That had crossed my mind ... but it seems there's around 80 or 100 > lines of good stuff there that'd be a shame to duplicate. If only
I suppose that's only if I want to continue using SFRM_ValuePerCall mode. SFRM_Materialize mode could remove a good deal of complexity currently in PL/Java around managing memory contexts, SPI_connect, etc. through multiple calls ... and I'd also have fn_extra all to myself. Until now, I had assumed that SFRM_ValuePerCall mode might offer some benefits, such as the possibility of pipelining certain queries and not building up a whole tuplestore in advance. But looking in the code, I'm getting the impression that those benefits are only theoretical future ones, as ExecMakeTableFunctionResult implements SFRM_ValuePerCall mode by ... repeatedly calling the function to build up a whole tuplestore in advance. Am I right about that? Are there other sites from which a SRF might be called that I haven't found, where ValuePerCall mode might actually support some form of pipelining? Are there actual cases where allowedModes might not contain SFRM_Materialize? Or is the ValuePerCall variant currently there just to support possible future such cases, none of which exist at the moment? Regards, -Chap
