Functions returning complex types.

"Thomas Hallgren" <thhal@mailblocks.com> writes:

I'm trying to use a function that returns a complex type. I have no problem
creating the function but when I try to use it I get the message:

ERROR: function in FROM has unsupported return type

AFAICS it's not possible to get that message for a function returning a
composite type. You'd better show exactly what you did.

regards, tom lane

The unsupported return type was all my fault. The Form_pg_type typrelid
attribute points to the class of the relation, not the relation as such.
Duh...

But now, when I actually can return complex types, I encounter another
problem. It happens when I pass a complex type returned from one function as
a complex parameter to another function, i.e. something like:

SELECT printMyComplexType(obtainMyComplexType());

Some research shows that the TupleTableSlot* that I create in
obtainMyComplexType() using the following code:

TupleDesc tupleDesc = TypeGetTupleDesc(typeId, NIL);
TupleTableSlot* slot = TupleDescGetSlot(tupleDesc);
return TupleGetDatum(slot, tuple);

is exactly the same TupleTableSlot* that is passed into my
printMyComplextType function. This is of course extremely bad since the
MemoryContext where it was allocated has gone out of scope (I guess, since
this is another call). AFAICS, the way I do it is by the book. What am I
doing wrong?

Regards,

Thomas Hallgren

"Tom Lane" <tgl@sss.pgh.pa.us> wrote in message
news:8715.1075138866@sss.pgh.pa.us...

"Thomas Hallgren" <thhal@mailblocks.com> writes:

I'm trying to use a function that returns a complex type. I have no

problem

"Thomas Hallgren" <thhal@mailblocks.com> writes:

... exactly the same TupleTableSlot* that is passed into my
printMyComplextType function. This is of course extremely bad since the
MemoryContext where it was allocated has gone out of scope (I guess, since
this is another call).

I don't think so; unless you are hacking memory contexts internally to
your function. Here's some empirical proof that the function call
mechanism is not broken:

regression=# create type mytype as (f1 int ,f2 int);
CREATE TYPE
regression=# create function obtaintype(int,int) returns mytype as
regression-# 'select $1,$2' language sql;
CREATE FUNCTION
regression=# select * from obtaintype(1,2);
f1 | f2
----+----
1 | 2
(1 row)

regression=# create function usetype(mytype) returns int as
regression-# 'select $1.f1 + $1.f2' language sql;
CREATE FUNCTION
regression=# select usetype(obtaintype(1,2));
usetype
---------
3
(1 row)

regards, tom lane

I found the following piece of code in the plpgsql pl_comp.c module:

/*
* This is a bit ugly --- need a permanent copy of the rel's tupdesc.
* Someday all these mallocs should go away in favor of a per-function
* memory context ...
*/
oldcxt = MemoryContextSwitchTo(TopMemoryContext);
row->rowtupdesc = CreateTupleDescCopy(RelationGetDescr(rel));
MemoryContextSwitchTo(oldcxt);

My guess is that the SQL functions do something similar (pre-compile and
store all TupleDesc's in TopMemoryContext), hence there's no problem with
your example. Writing a C function I get a TupleDesc from the
TypeGetTupleDesc() function that has been allocated using palloc(). I'm
quite sure I don't do anything with memory contexts and the TupleDesc really
seems to go out of scope when the function returns.

If I create a copy of the TupleDesc in the TopMemoryContext directly after
the call to TypeGetTupleDesc, then everything works just fine.

I still suspect that something is broken with the calling mechanism. At
least for languages that do not compile the stuff into permanent structures
prior to evaluating.

Regards,

Thomas Hallgren

"Tom Lane" <tgl@sss.pgh.pa.us> wrote in message
news:14875.1075149255@sss.pgh.pa.us...

"Thomas Hallgren" <thhal@mailblocks.com> writes:

... exactly the same TupleTableSlot* that is passed into my
printMyComplextType function. This is of course extremely bad since the
MemoryContext where it was allocated has gone out of scope (I guess,

since