You could actually get the tupdesc from the caller if you wanted. See, for example crosstab_hash() in contrib/tablefunc:Thank you for point.
<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>
Ok, I see
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.
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: [EMAIL PROTECTED]
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster