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.
> 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.
> 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
> 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
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....
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-06-27 15:34:34|
|Subject: Re: Re: Encrypting pg_shadow passwords |
|Previous:||From: Frank Ch. Eigler||Date: 2001-06-27 15:27:07|
|Subject: Re: Re: Encrypting pg_shadow passwords|