Joe Conway <[EMAIL PROTECTED]> writes: >> I suppose that ExecMakeTableFunctionResult could be changed to *always* >> pass ReturnSetInfo, even if it's not expecting the function to return >> a set. That seems even less clean; but it would work, at least in the >> current implementation.
> Hmmm. I hadn't thought about this possibility. Why is it unclean? Are > there places where the lack of ReturnSetInfo is used to indicate that > the function does not return a set? Doesn't seem like there should be. Probably not. If the function itself doesn't know whether it should return a set, it can always look at the FmgrInfo struct to find out. > Actually, I left off trying to figure out how to pass the columndef to > ExecMakeFunctionResult in the first place. That was hard yesterday, but it's easy today because nodeFunctionscan isn't using ExecEvalExpr anymore --- we'd only have to add one more parameter to ExecMakeTableFunctionResult and we're there. > Preference of extending FunctionCallInfoData or ReturnSetInfo? Definitely ReturnSetInfo. If we put it in FunctionCallInfoData then that's an extra word to zero for *every* fmgr function call, not only table functions. One thing to notice is that a table function that's depending on this info being available will have to punt if it's invoked via ExecMakeFunctionResult (ie, it's being called in a SELECT targetlist). That doesn't bother me too much, but maybe others will see it differently. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]