On Wed, 27 Jun 2001, Karel Zak wrote:
> On Tue, Jun 26, 2001 at 05:11:47PM -0400, Alex Pilosov wrote:
> > I started thinking about Tom's idea to implement functions as table
> > source.
> >
> > To me, it seems that a very few changes are necessary:
> > a) parser must be changed to allow functioncall to be a table_ref
> > (easy)
> >
> > b) when a Query node is generated out of such a call "select * from foo()"
> > it should be almost identical to one generated out of "select * from
> > (select * from foo)" with one distinction: list of query attributes should
> > be completed based on return type of foo().
>
> 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.
> 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.
> > c) executor should support execution of such Query node, properly
> > extracting things out of function's return value and placing them into
> > result attributes.
>
> d) changes in fmgr
Don't think that's necessary, but I guess I'll find out when I try it :)
> e) SPI support for table building/filling inside foo()
As far as SPI is concerned, its the same as current: function returning
records must return pointer to HeapTuple containing the record.
