Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
> Cursors simply address the problem of "impedance mismatch" (the use of
> that term in this way probably pre-dates ORM, so please don't tell me
> that that term refers exclusively to an ORM problem within an RDBMS
> context). You don't have to fetch the result set all at once where
> that is impractical. However, the entire result set is available on
> the server from the first fetch.
The above statements are not true as far as the cursor mechanism is
concerned (at least not in Postgres). However, they are true as far as
the result of a plpgsql function returning set is concerned. The
function runs to completion, dumping RETURN NEXT outputs into a
"tuplestore", and then returns the tuplestore as its result.
It is possible to code set-returning functions in a suspend-and-resume
style, but none of the available PLs do that; you have to get down to
the C level.
regards, tom lane
