Tom Lane wrote: > John Gray <[EMAIL PROTECTED]> 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 ---------------------------(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
