Re: Return unknown resultset from a function - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Return unknown resultset from a function
Date
Msg-id CAHyXU0y=Ukp01tVw0XqGNcN6Vw_4i81L0hvzGYwKMx6N8pX3XQ@mail.gmail.com
Whole thread Raw
In response to Re: Return unknown resultset from a function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Mon, Mar 5, 2012 at 10:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> The only exception to this rule is cursors.  Reading from cursors via
>> FETCH allows you to pull data from a refcursor that was set up in a
>> previous function call and works pretty well, but comes with the giant
>> downside that the results can be directed only to the client.
>
> Hmm, couldn't you do a FETCH into a record variable in plpgsql?  Not
> that you'd not have problems manipulating the record variable, since
> plpgsql is pretty strongly typed itself.

Yeah -- good point on both sides -- you can do it, but it's pretty
limiting: you can only fetch a row at a time and the result data can't
be further expressed in another query.  A CTE based FETCH has been
suggested a couple of times as a hypothetical workaround.

Whether the data is processed on the server or the client the result
essentially the result is the same...you're forced into a highly
iterative method of programming that I try to avoid whenever possible.

TBH though I find the textual workarounds to the type system to work
pretty well, meaning that most of the useful things which were
historically only possible in C have been nicely wrapped or seem to be
just plain impossible (like handling mixed type variadic functions, or
receiving generic RECORDs as arguments).

merlin

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Memory usage and configuration settings
Next
From: Merlin Moncure
Date:
Subject: Re: Memory usage and configuration settings