Skip site navigation (1) Skip section navigation (2)

Re: functions returning records

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Jan Wieck <JanWieck(at)yahoo(dot)com>
Cc: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions returning records
Date: 2001-06-27 15:31:09
Message-ID: Pine.BSO.4.10.10106271124240.598-100000@spider.pilosoft.com (view raw or flat)
Thread:
Lists: 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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-06-27 15:34:34
Subject: Re: Re: Encrypting pg_shadow passwords
Previous:From: Frank Ch. EiglerDate: 2001-06-27 15:27:07
Subject: Re: Re: Encrypting pg_shadow passwords

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group