Peter Geoghegan <peter.geoghegan86@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
