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
executornode 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@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
