Tom Lane wrote:
> John Gray <jgray(at)azuli(dot)co(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-08-30 15:08:09|
|Subject: Re: contrib features during beta period |
|Previous:||From: Bruce Momjian||Date: 2002-08-30 14:53:19|
|Subject: Re: tweaking MemSet() performance|