Re: [HACKERS] Function returns composite type

[Teodor Sigaev]

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: [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster