gh-128505: Expose an interface to sqlite3_file_control #128507
Conversation
|
All commit authors signed the Contributor License Agreement. |
hashbrowncipher
force-pushed
the
sqlite3_file_control
branch
from
f36b975 to
e32c372
Compare
| @@ -0,0 +1 @@ | |||
| sqlite Connection objects now expose a method set_file_control, which is a thin wrapper for `sqlite3_file_control https://www.sqlite.org/c3ref/file_control.html`_. | |||
There was a problem hiding this comment.
See https://devguide.python.org/documentation/markup/ for help with docs markup.
Modules/_sqlite/connection.c
Outdated
| /*[clinic end generated code: output=d9d2d311892893b6 input=0253798d9514fea2]*/ | ||
| { | ||
| int rc; | ||
| long val = arg; |
There was a problem hiding this comment.
Not all sqlite3_file_control opcodes use the int1 datatype. For example SQLITE_FCNTL_VFSNAME and SQLITE_FCNTL_TEMPFILENAME are char *. Suggesting to limit this (like we do for sqlite3_db_config) to only the supported opcodes, and raise an exception for unsupported opcodes.
In any case, we should use int here.
| long val = arg; | |
| int val = arg; |
Footnotes
-
int, notlong↩
There was a problem hiding this comment.
Please also address the first part of this remark.
| Py_END_ALLOW_THREADS | ||
|
|
||
| if (rc != SQLITE_OK) { | ||
| PyErr_SetString(self->ProgrammingError, sqlite3_errstr(rc)); |
There was a problem hiding this comment.
ProgrammingError may not be the right fit for all opcodes. Ideally, we should use a variant of _pysqlite_seterror where we pass an error code instead of a SQLite database pointer. Perhaps I should make such an internal API available first.
There was a problem hiding this comment.
I'd be happy to use any internal API that you build for this purpose.
hashbrowncipher
force-pushed
the
sqlite3_file_control
branch
from
223328f to
4867672
Compare
|
Just a heads-up: we normally do not force-push. PRs are squashed into a single commit when we merge to |
|
|
||
| op: int | ||
| The SQLITE_FCNTL_* constant to invoke. | ||
| arg: long |
There was a problem hiding this comment.
Let's stick with int, since that's the datatype used by SQLite for these opcodes.
| arg: long | |
| arg: int |
| sqlite Connection objects now expose a method | ||
| :meth:`sqlite3.Connection.file_control`, which is a thin wrapper for | ||
| `sqlite3_file_control <https://www.sqlite.org/c3ref/file_control.html>`_. |
There was a problem hiding this comment.
You also need to add docs for file_control. See Doc/library/sqlite3.rst.
sqlite3_file_control can affect the semantics of a sqlite3 database, but is not exposed by the sqlite.Connection class. In particular, this allows callers to use the SQLITE_FCNTL_PERSIST_WAL opcode. SQLITE_FCNTL_PERSIST_WAL ensures that callers can open a WAL-mode database on a read-only mount even when the writers have closed the DB.