Re: functions returning records

On Wed, 27 Jun 2001, Jan Wieck wrote:

> My idea on that is as follows:
>
> 1. Adding a new relkind that means 'record'. So we use
> pg_class, pg_attribute and pg_type as we do for tables
> and views to describe a structure.
Okay

> 2. A function that RETURNS SETOF record/table/view is
> expected to return a refcursor (which is basically a
> portal name - SPI support already in 7.2), who's tupdesc
> matches the structure.
Okay, but that will break whatever currently written functions which
return setof. Although it could be considered a good thing, as its too
ugly now :)

> 3. The Func node for such a function invocation will call
> the function with the appropriate arguments to get the
> portal, receive the tuples with an internal fetch method
> one per invocation (I think another destination is
> basically enough) and close the portal at the end.
OK

> 4. Enhancement of the portal capabilities. A new function
> with a tuple descriptor as argument creates a special
> portal that simply opens a tuple sink. Another function
> stores a tuple there and a third one rewinds the sink and
> switches the portal into read mode, so that fetches will
> return the tuples again. One format of the tuple sink is
> capable of backward moves too, so it'll be totally
> transparent.
OK

> 5. Enhancement of procedural languages that aren't
> implemented as state machines (currently all of them) to
> use the tuple-sink-portals and implement RETURN AND
> RESUME.
I'm not sure I understand this one correctly. Could you explain what
you mean here by 'use'?

What is "RETURN AND RESUME"? Do you mean a function that precomputes
entire result set before stuffing it into portal?

> This plan reuses alot of existing code and gains IMHO the
> most functionality. All portals are implicitly closed at the
> end of a transaction. This form of internal portal usage
> doesn't require explicit transaction blocks (as of current
> 7.2 tree). All the neat buffering, segmenting of the tuple
> sink code for materializing the result set comes into play.
> From the executors POV there is no difference between a
> function returning a portal that's a real SELECT, collecting
> the data on the fly, or a function materializing the result
> set first with RETURN AND RESUME. The tuple structure
> returned by a function is not only known at parsetime, but
> can be used in other places like for %ROWTYPE in PL/pgSQL.

I think I once again got myself in over my head :) But I'm going to try to
code this thing anyway, with great suggestions from Karel and you....

-alex