Re: Return unknown resultset from a function
От | Merlin Moncure |
---|---|
Тема | Re: Return unknown resultset from a function |
Дата | |
Msg-id | CAHyXU0y=Ukp01tVw0XqGNcN6Vw_4i81L0hvzGYwKMx6N8pX3XQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Return unknown resultset from a function (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: