Re: functions returning records - Mailing list pgsql-hackers

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