Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group