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

Re: Accessing original TupleDesc from SRF

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:45:07
Message-ID: 3D6F9303.9080608@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>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.

I didn't even realize you had changed that! Things move quickly around 
here ;-). I'll take a look this morning.


>>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.

OK.


> 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.

It's an important safety tip, but it doesn't bother me either. I think 
you have suggested before that SRFs in SELECT targetlists should be 
deprecated/removed. I'd take that one step further and say that SELECT 
targetlists should only allow a scalar result, but obviously there are 
some backwards compatibility issues there.

Joe



In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2002-08-30 15:48:22
Subject: Re: contrib features during beta period
Previous:From: Iavor RaytchevDate: 2002-08-30 15:44:12
Subject: pgaccess - where to store the own data

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