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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-06-27 15:34:34 | Re: Re: Encrypting pg_shadow passwords |
Previous Message | Frank Ch. Eigler | 2001-06-27 15:27:07 | Re: Re: Encrypting pg_shadow passwords |