Thread: SRFs ExecMakeTableFunctionResult

Greets,

While I was finishing up SRF support in PL/Py, I noticed that when VPC is the
selected mode for a table function, ExecMakeTableFunctionResult will set
rsinfo.isDone to ExprSingleResult each time it loops to fetch another value
(when a direct_function_call). This makes the VPC-SRF author set isDone to
ExprMultipleResult on _every_ call while returning values, as it will break
out if rsinfo.isDone != ExprMultipleResult.

Is this the desired behavior?

--
Regards,       James William Pye

James William Pye <flaw@rhid.com> writes:
> While I was finishing up SRF support in PL/Py, I noticed that when VPC is the
> selected mode for a table function, ExecMakeTableFunctionResult will set
> rsinfo.isDone to ExprSingleResult each time it loops to fetch another value
> (when a direct_function_call). This makes the VPC-SRF author set isDone to
> ExprMultipleResult on _every_ call while returning values, as it will break
> out if rsinfo.isDone !=3D ExprMultipleResult.

> Is this the desired behavior?

Seems reasonable to me.  A SRF function really ought to explicitly set
isDone on every call anyway.
        regards, tom lane

> Seems reasonable to me.  A SRF function really ought to explicitly set
> isDone on every call anyway.

Aye, it seems reasonable, but a bit inconsistent with the effect of
ExecMakeFunctionResult, which does the same thing but bases the continuity of
the result gathering on the isDone pointer, which is set to
ExprMultipleResult if isDone is not ExprEndResult, thus making it continue
until rsinfo.isDone is explicitly set to ExprEndResult, unlike table
functions which will end on either SingleResult or EndResult.
(Around lines #941-984 in execQual.c)

Is this inconsistency desired?

My confusion came in when I implemented SRFs that worked with non-table
SRFs, and then table functions didn't work because I wasn't setting isDone
to MultipleResult every call.

--
Regards,       James William Pye