Определите, пишет ли SQL-оператор базу данных

int sqlite3_stmt_readonly(sqlite3_stmt *pStmt);

sqlite3_stmt_readonly(X) возвращает true (не 0), если и только если подготовленный запрос X не вносит прямых изменений в содержание файла базы данных.

Обратите внимание на то, что определенные приложением функции SQL или виртуальные таблицы могли бы изменить базу данных косвенно как побочный эффект. Например, если приложение определяет функцию "eval()", которая вызывает sqlite3_exec(), следующий SQL-оператор изменил бы файл базы данных через побочные эффекты:

SELECT eval('DELETE FROM t1') FROM t2;

Но потому что SELECT не изменяет файл базы данных непосредственно, sqlite3_stmt_readonly() все еще возвратил бы true.

Команды управления транзакциями, такие как BEGIN, COMMIT, ROLLBACK, SAVEPOINT и RELEASE, заставляют sqlite3_stmt_readonly() вернуть true, так как сами запросы на самом деле не изменяют базу данных, а скорее они управляют выбором времени, когда другие запросы изменяют базу данных. ATTACH и DETACH также заставляют sqlite3_stmt_readonly() вернуть true: они изменяют конфигурацию соединения с базой данных, но не вносят изменения в содержание файлов базы данных на диске. sqlite3_stmt_readonly() вернет true для BEGIN, поскольку BEGIN устанавливает внутренние флаги, но BEGIN IMMEDIATE и BEGIN EXCLUSIVE действительно касаются базы данных, значит для них sqlite3_stmt_readonly() вернет false.

Это вернет false, если есть возможность, что запрос мог бы изменить файл базы данных. Возврат false не гарантирует, что запрос изменит файл базы данных. Например, у запроса UPDATE мог бы быть оператор WHERE, который делает его нерабочим, но результат sqlite3_stmt_readonly() все еще был бы false. Точно так же CREATE TABLE IF NOT EXISTS является только для чтения, когда таблица уже существует, но sqlite3_stmt_readonly() вернет false.

Если подготовленный запрос X это EXPLAIN или EXPLAIN QUERY PLAN, sqlite3_stmt_readonly(X) вернет то же самое значение, как будто префикс EXPLAIN или EXPLAIN QUERY PLAN пропущен.