> It seems you're right, I built a simple test-case (see attachment) using timeofday(). The numbers from fetching from a cursor over the set-returning function run away from the selects that directly call timeofday() in between. > In my case I pause the _client_ between calls, but the results are the same. > Peculiar... > 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. What I want to do is to fetch the beginning of the result set before the end has even been determined, with the fetching potentially blocking in my app to let the plpgsql function catch up and generate a row that didn't even exist on the server before, and for a time after the most recent fetch. That is fundamentally different to how cursors are typically used, and I hope that there is a way to do it. Thanks, Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
