Updated: 2025/Nov/16

Please read Privacy Policy. It's for your privacy.

SQLITE3_STMT_READONLY(3)   Library Functions Manual   SQLITE3_STMT_READONLY(3)

NAME
     sqlite3_stmt_readonly - determine if an SQL statement writes the database

SYNOPSIS
     #include <sqlite3.h>

     int
     sqlite3_stmt_readonly(sqlite3_stmt *pStmt);

DESCRIPTION
     The sqlite3_stmt_readonly(X) interface returns true (non-zero) if and
     only if the prepared statement X makes no direct changes to the content
     of the database file.

     Note that application-defined SQL functions or virtual tables might
     change the database indirectly as a side effect.  For example, if an
     application defines a function "eval()" that calls sqlite3_exec(), then
     the following SQL statement would change the database file through side-
     effects:


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


     But because the SELECT statement does not change the database file
     directly, sqlite3_stmt_readonly() would still return true.

     Transaction control statements such as BEGIN, COMMIT, ROLLBACK,
     SAVEPOINT, and RELEASE cause sqlite3_stmt_readonly() to return true,
     since the statements themselves do not actually modify the database but
     rather they control the timing of when other statements modify the
     database.  The ATTACH and DETACH statements also cause
     sqlite3_stmt_readonly() to return true since, while those statements
     change the configuration of a database connection, they do not make
     changes to the content of the database files on disk.  The
     sqlite3_stmt_readonly() interface returns true for BEGIN since BEGIN
     merely sets internal flags, but the BEGIN IMMEDIATE and BEGIN EXCLUSIVE
     commands do touch the database and so sqlite3_stmt_readonly() returns
     false for those commands.

     This routine returns false if there is any possibility that the statement
     might change the database file.  A false return does not guarantee that
     the statement will change the database file.  For example, an UPDATE
     statement might have a WHERE clause that makes it a no-op, but the
     sqlite3_stmt_readonly() result would still be false.  Similarly, a CREATE
     TABLE IF NOT EXISTS statement is a read-only no-op if the table already
     exists, but sqlite3_stmt_readonly() still returns false for such a
     statement.

     If prepared statement X is an EXPLAIN or EXPLAIN QUERY PLAN statement,
     then sqlite3_stmt_readonly(X) returns the same value as if the EXPLAIN or
     EXPLAIN QUERY PLAN prefix were omitted.

IMPLEMENTATION NOTES
     These declarations were extracted from the interface documentation at
     line 4368.

     SQLITE_API int sqlite3_stmt_readonly(sqlite3_stmt *pStmt);

SEE ALSO
     sqlite3_exec(3), sqlite3_stmt(3)

NetBSD 11.99                   January 24, 2024                   NetBSD 11.99