Pagination over fetched results or lazy cursor?

[ericsteele]

Hello,

I have a quick question about how this cursor implementation works. Currently, it seems to me that it could be implemented in the following ways:

1. Cursor retrieves rows and then provides pagination over those rows.
2. Cursor fetches rows as needed in a lazy fashion.

Is one of these two understandings correct?

Thank you,
Eric

[jeromew]

The module uses the cursor feature of the pg protocol.
A limited number of rows are retrieved only when there are asked for via the read(number_of_rows,.. call.

So the module fits in the "lazy" alternative.

[brianc]

There was a post by @Koi9 that went missing, but here it is:

By conforming to PostgreSQL Front-End/Back-End Protocol, the author simply sends an extended query to the PostgreSQL server. The server then creates a prepared statement for the query. The protocol allowed client to set specific number of rows to return when the prepared statement is executed. Internally, PostgreSQL server creates a cursor to keep track of the current row. After each execution, the cursor is moved behind the last returned row. Hence, by continue to call cursor#read(), you simple EXECUTE the prepared statement again with a new/same number of rows, starting at the next one. You can do this manually using query such as "DECLARE" but this module's implementation is very well done.

I hope this helps @ericsteele!