Repository navigation
[sqlite3] lazy creation of result rows #89139
Description
Activity
Currently, we build the first result row in the _pysqlite_query_execute() loop if sqlite3_step() returned SQLITE_ROW. When the user asks for a row (for example, using sqlite3.Cursor.fetchone()), this pre-built row is returned, and the next row is prepared.
Suggesting to lazily build result rows instead.
Cons:
- no result tuples are built unless sqlite3.Cursor.fetch*() is called
- no need to keep the next result row (tuple) in pysqlite_Cursor; rows are built on demand
- pysqlite_cursor_iternext() is vastly simplified (50% less lines of code)
- the main loop in _pysqlite_query_execute() is further simplified
Cons:
- code churn
git diff main --shortstat: 2 files changed, 29 insertions(+), 58 deletions(-)
Historical note:
The current behaviour was introduced in pysqlite v2.0.2 (May 21 2005), in order to be able to finalise statements and thus close cursors as soon as possible. However, that effect was cancelled just after a couple of months, by the addition of the LRU cache and the ability to reuse prepared statements.
sqlite3result rows #27884Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: