> 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
