Thread: AW: functions returning records

AW: functions returning records

From
Zeugswetter Andreas SB
Date:
> >  For the result from foo() you must somewhere define attributes (names). 
> > Where? In CREATE FUNCTION statement? Possible must be:
> Function must be returning an existing reltype. I understand its a major
> restriction, but I can't think of a better way.

Yup, that's how Informix does it. It has a "create row type" command, 
so you don't actually need a table.
> 
> >  select name1, name2 from foo() where name1 > 10;
> > 
> >  What returns foo()? ...the pointer to HeapTuple or something like this or
> > pointer to some temp table?
> Pointer to heaptuple. We can get to tupdesc for that tuple by looking up
> its prorettype.

But the question is how you get the next row. Do you return a null terminated 
array of heaptuples ?

Imho to allow this to be efficient, there would need to be some mechanism, 
that would allow the function to return the result in small blocks (e.g. each row)
(similar to a heap access), else you would be limited to return 
values, that fit into memory, or fit on temporary disk storage, and do 
work that might not even be required, because the client only fetches the 
first row.

Andreas


Re: AW: functions returning records

From
Alex Pilosov
Date:
On Wed, 27 Jun 2001, Zeugswetter Andreas SB wrote:

> > >  select name1, name2 from foo() where name1 > 10;
> > > 
> > >  What returns foo()? ...the pointer to HeapTuple or something like this or
> > > pointer to some temp table?
> > Pointer to heaptuple. We can get to tupdesc for that tuple by looking up
> > its prorettype.
> 
> But the question is how you get the next row. Do you return a null terminated 
> array of heaptuples ?
> 
> Imho to allow this to be efficient, there would need to be some mechanism, 
> that would allow the function to return the result in small blocks (e.g. each row)
> (similar to a heap access), else you would be limited to return 
> values, that fit into memory, or fit on temporary disk storage, and do 
> work that might not even be required, because the client only fetches the 
> first row.
I haven't thought of this yet, but its a good point. I think I'll find out
what's involved when I write code for it. :)

-alex