Re: functions returning sets

Alex Pilosov wrote:
> Well, I'm on my way to implement what was discussed on list before.
>
> I am doing it the way Karel and Jan suggested: creating a
> pg_class/pg_attribute tuple[s] for a function that returns a setof.

That's not exactly what I suggested. I meant having a
separate

CREATE TYPE <typname> IS RECORD OF (<atttyplist>);

and then

CREATE FUNCTION ...
RETURNS SETOF <typname>|<tablename>|<viewname> ...

Note that we need a pg_type entry too as we currently do for
tables and views. The only thing missing is a file underneath
and of course, the ability to use it directly for INSERT,
UP... operations.

This way, you have the functions returned tuple structure
available elsewhere too, like in PL/pgSQL for %ROWTYPE,
because it's a named type declaration.

> Now, more interesting question, what's the best way to interface ExecScan
> to function-executing machinery:
>
> Options are:
>
> 1) Create a special scan node type, T_FuncSeqScan and deal with it there.
>
> 2) Keep the T_SeqScan, explain to nodeSeqScan special logic when dealing
> with RELKIND_FUNC relations.
> (I prefer this one, but I would like a validation of it)
>
> 3) explain to heap_getnext special logic.

My idea was to change the expected return Datum of a function
returning SETOF <rowtype> beeing a refcursor or portal
directly. Portals are an abstraction of a resultset and used
in Postgres to implement cursors. So the executor node would
be T_PortalScan. Whatever a function needs (callback per
tuple, tuple sink to stuff, an executor like now) will be
hidden in the portal.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com