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 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. Anyone have a better idea? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster