Re: Accessing original TupleDesc from SRF

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: John Gray <jgray(at)azuli(dot)co(dot)uk>, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Accessing original TupleDesc from SRF
Date: 2002-08-30 15:26:06
Message-ID: 986.1030721166@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:
>> 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.

Probably not. If the function itself doesn't know whether it should
return a set, it can always look at the FmgrInfo struct to find out.

> Actually, I left off trying to figure out how to pass the columndef to
> ExecMakeFunctionResult in the first place.

That was hard yesterday, but it's easy today because nodeFunctionscan
isn't using ExecEvalExpr anymore --- we'd only have to add one more
parameter to ExecMakeTableFunctionResult and we're there.

> Preference of extending FunctionCallInfoData or ReturnSetInfo?

Definitely ReturnSetInfo. If we put it in FunctionCallInfoData then
that's an extra word to zero for *every* fmgr function call, not only
table functions.

One thing to notice is that a table function that's depending on this
info being available will have to punt if it's invoked via
ExecMakeFunctionResult (ie, it's being called in a SELECT targetlist).
That doesn't bother me too much, but maybe others will see it
differently.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-08-30 15:33:40 Re: Accessing original TupleDesc from SRF
Previous Message Bruce Momjian 2002-08-30 15:24:16 Re: fix for palloc() of user-supplied length