Re: Function returns composite type
От | Joe Conway |
---|---|
Тема | Re: Function returns composite type |
Дата | |
Msg-id | 3EE74D1B.6070909@joeconway.com обсуждение исходный текст |
Ответ на | Re: Function returns composite type (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: Function returns composite type
|
Список | pgsql-hackers |
Teodor Sigaev wrote: > it's a great pity :(. > > But in function I already make TupleDesc: > tupdesc = CreateTemplateTupleDesc(attnum, false); > for (i = 0; i < attnum; i++) { > sprintf(attname, "z%d", i+1); > TupleDescInitEntry(tupdesc, i+1, attname, INT4OID, -1, > 0, false); > } > As I understand, this code makes full description of returning value, > including types and column's names. > Is this info used anywhere? 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> 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. Joe
В списке pgsql-hackers по дате отправления: