Re: Accessing original TupleDesc from SRF

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