50 lines
1.7 KiB
Groff
50 lines
1.7 KiB
Groff
.Dd March 11, 2017
|
|
.Dt SQLITE3_STMT_READONLY 3
|
|
.Os
|
|
.Sh NAME
|
|
.Nm sqlite3_stmt_readonly
|
|
.Nd Determine If An SQL Statement Writes The Database
|
|
.Sh SYNOPSIS
|
|
.Ft int
|
|
.Fo sqlite3_stmt_readonly
|
|
.Fa "sqlite3_stmt *pStmt"
|
|
.Fc
|
|
.Sh 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.
|
|
.Pp
|
|
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:
|
|
.Bd -ragged
|
|
.Bd -literal
|
|
SELECT eval('DELETE FROM t1') FROM t2;
|
|
.Ed
|
|
.Pp
|
|
.Ed
|
|
.Pp
|
|
But because the SELECT statement does not change the database
|
|
file directly, sqlite3_stmt_readonly() would still return true.
|
|
.Pp
|
|
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.
|
|
.Sh SEE ALSO
|
|
.Xr sqlite3_create_function 3 ,
|
|
.Xr sqlite3_stmt 3 ,
|
|
.Xr sqlite3_exec 3
|