Tom Lane wrote: > Joe Conway <[EMAIL PROTECTED]> writes: >>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.
I didn't even realize you had changed that! Things move quickly around here ;-). I'll take a look this morning. >>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. OK. > 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. It's an important safety tip, but it doesn't bother me either. I think you have suggested before that SRFs in SELECT targetlists should be deprecated/removed. I'd take that one step further and say that SELECT targetlists should only allow a scalar result, but obviously there are some backwards compatibility issues there. Joe ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
