You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2021-11-10.21:40:29.743>created_at=<Date2021-11-08.17:40:00.947>labels= ['extension-modules', 'type-bug', '3.11']
title='[sqlite3] SQLITE_LIMIT_LENGTH is incorrectly used to check statement length'updated_at=<Date2021-11-10.21:40:29.742>user='https://github.com/erlend-aasland'
### Alternative 1:
Quick fix is to check against SQLITE_LIMIT_SQL_LENGTH instead of SQLITE_LIMIT_LENGTH.
### Alternative 2:
Let SQLite do the check for us, and instead add integer overflow check, since Py_ssize_t may be larger than int (sqlite3_prepare_v2() uses an int as the max statement length parameter).
### Alternative 3:
As alternative 2, but alter the sqlite3_prepare_v2() call to accept _any_ length (max statement length = -1).
In alternative 1 we control the type and the message of exception. In alternative 3 we left this to the SQLite3 engine. It is difficult to keep consistency in alternative 2, errors raised for sizes less and larger than INT_MAX can be different. I think this is a serious drawback of this alternative.
What happens if set SQLITE_LIMIT_SQL_LENGTH to 0 or negative value? Would it be interpreted as "no limit"?