Re: Function returns composite type

> You could actually get the tupdesc from the caller if you wanted. See, 
> for example crosstab_hash() in contrib/tablefunc:
> 
> <snip>
>   /* check to see if caller supports us returning a tuplestore */
>   if (!rsinfo || !(rsinfo->allowedModes & SFRM_Materialize))
>     elog(ERROR, "crosstab: materialize mode required, but it is not "
>                 "allowed in this context");
> 
>   per_query_ctx = rsinfo->econtext->ecxt_per_query_memory;
>   oldcontext = MemoryContextSwitchTo(per_query_ctx);
> 
>   /* get the requested return tuple description */
>   tupdesc = CreateTupleDescCopy(rsinfo->expectedDesc);
> </snip>
Thank you for point.


> 
> The problem is that the parser needs the column data types long before 
> your function gets called by the executor. Therefore you either need the 
> predetermined return type, or the query string definition.
Ok, I see

> 
> We've discussed a couple of times allowing the parser to "interrogate" 
> the function at parse time to let it determine what the runtime tupdesc 
> will be, but I haven't been able to come up with a good way to do that.


Can we make follow:
Functions, returning record and called in sql without description,
??lled with specific arguments (as is done for SRF by SRF_IS_FIRSTCALL()). With 
this arguments it should return TupleDesc.
As I see, the place to such call is addRangeTableEntryForFunction at 
src/parser/parse_relation.c near lines N921-964. In this place we have all that 
we need.

Am I wrong?



-- 
Teodor Sigaev                                  E-mail: teodor@sigaev.ru