Re: Maximum function call nesting depth for regression tests

I wrote:
> I haven't looked to see if any of these have an excessive amount of
> local variables.

I poked through the call stack and found that the only function in
this nest that seems to have a large amount of local variables is
ExecMakeFunctionResult(). The space hog there is the local
FunctionCallInfoData struct, which requires ~500 bytes on a 32-bit
machine and ~900 bytes on a 64-bit one. Now the interesting thing
about that is that we *also* keep a FunctionCallInfoData struct in
the FuncExprState. The reason for this redundancy is stated to be:

/*
* For non-set-returning functions, we just use a local-variable
* FunctionCallInfoData. For set-returning functions we keep the callinfo
* record in fcache->setArgs so that it can survive across multiple
* value-per-call invocations. (The reason we don't just do the latter
* all the time is that plpgsql expects to be able to use simple
* expression trees re-entrantly. Which might not be a good idea, but the
* penalty for not doing so is high.)
*/

AFAICS this argument is no longer valid given the changes we made last
week to avoid collisions due to reuse of fcinfo->flinfo->fn_extra.
I'm pretty strongly tempted to get rid of the local-variable
FunctionCallInfoData and just use the one in the FuncExprState always.
That would simplify and marginally speed up the function-call code,
which seems surely worth doing regardless of any savings in stack
depth.

I'm not sure that this would save enough stack space to make the
buildfarm critters happy, but it might. However, I wouldn't care
to risk changing this in the back branches, so we'd still need some
other plan for fixing the buildfarm failures.

Any objections?

regards, tom lane