On 05/07/2010 09:06 PM, Nikhil Sontakke wrote: >>> Yeah this is my basic confusion. But wouldn't the arguments be >>> evaluated afresh on the subsequent call for this SRF? >> >> No, see ExecMakeFunctionResult(). If we did that we'd have serious >> problems with volatile functions, ie srf(random()). > > Ok thanks. So if someone uses a really long-running srf with argument > expression evaluations thrown in, then running into "out of memory" > issues should be expected and then in those cases they are better off > using multiple srf calls to get the same effect if they can..
I've very recently looked into this exact case myself for someone, and came to the conclusion that there is no simple fix for this. If you want to see a concrete example of a query that fails, apply your patch and then run the regression tests -- the "misc" test will fail. I think this is an example of why we still need to implement a real SFRM_ValuePerCall mode that allows results to be pipelined. Yes, ValuePerCall sort of works from the targetlist, but it is pretty much useless for the use cases where people really want to use it. Or would a FROM clause ValuePerCall suffer the same issue? Joe
signature.asc
Description: OpenPGP digital signature
