Tom Lane wrote:
> John Gray <jgray@azuli.co.uk> writes:
>
>>Please correct me if I've got this wrong, but it appears from the SRF
>>API, that a SRF cannot readily refer to the TupleDesc to which it is
>>expected to conform (i.e. the TupleDesc derived from the FROM clause of
>>an original SELECT statement) because that is held in the executor state
>>and not copied or linked into the function context.
>
>
>>The reason I'm interested (and this might be a crazy idea) is that a
>>function might choose to adapt its output based on what it is asked for.
>
>
> Seems like a cool idea.
>
> We could fairly readily add a field to ReturnSetInfo, but that would
> only be available to functions defined as returning a set. That'd
> probably cover most useful cases but it still seems a bit unclean.
I thought about that, but had the same concern.
> 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.
> Anyone have a better idea?
I was looking to see if it could be added to FunctionCallInfoData, but
you might find that more unclean still ;-).
Actually, I left off trying to figure out how to pass the columndef to
ExecMakeFunctionResult in the first place. It wasn't obvious to me, and
since you offered an easy alternative solution I stopped trying. Any
suggestions? Preference of extending FunctionCallInfoData or
ReturnSetInfo? I'd really like to do this for 7.3.
Joe
