Small. Fast. Reliable.
Choose any three.

SQLite C Interface

Function Flags

#define SQLITE_DETERMINISTIC    0x000000800
#define SQLITE_DIRECTONLY       0x000080000
#define SQLITE_SUBTYPE          0x000100000
#define SQLITE_INNOCUOUS        0x000200000

These constants may be ORed together with the preferred text encoding as the fourth argument to sqlite3_create_function(), sqlite3_create_function16(), or sqlite3_create_function_v2().

SQLITE_DETERMINISTIC
The SQLITE_DETERMINISTIC flag means that the new function always gives the same output when the input parameters are the same. The abs() function is deterministic, for example, but randomblob() is not. Functions must be deterministic in order to be used in certain contexts such as with the WHERE clause of partial indexes or in generated columns. SQLite might also optimize deterministic functions by factoring them out of inner loops.

SQLITE_DIRECTONLY
The SQLITE_DIRECTONLY flag means that the function may only be invoked from top-level SQL, and cannot be used in VIEWs or TRIGGERs nor in schema structures such as CHECK constraints, DEFAULT clauses, expression indexes, partial indexes, or generated columns.

The SQLITE_DIRECTONLY flag is recommended for any application-defined SQL function that has side-effects or that could potentially leak sensitive information. This will prevent attacks in which an application is tricked into using a database file that has had its schema surreptiously modified to invoke the application-defined function in ways that are harmful.

Some people say it is good practice to set SQLITE_DIRECTONLY on all application-defined SQL functions, regardless of whether or not they are security sensitive, as doing so prevents those functions from being used inside of the database schema, and thus ensures that the database can be inspected and modified using generic tools (such as the CLI) that do not have access to the application-defined functions.

SQLITE_INNOCUOUS
The SQLITE_INNOCUOUS flag means that the function is unlikely to cause problems even if misused. An innocuous function should have no side effects and should not depend on any values other than its input parameters. The abs() function is an example of an innocuous function. The load_extension() SQL function is not innocuous because of its side effects.

SQLITE_INNOCUOUS is similar to SQLITE_DETERMINISTIC, but is not exactly the same. The random() function is an example of a function that is innocuous but not deterministic.

Some heightened security settings (SQLITE_DBCONFIG_TRUSTED_SCHEMA and PRAGMA trusted_schema=OFF) disable the use of SQL functions inside views and triggers and in schema structures such as CHECK constraints, DEFAULT clauses, expression indexes, partial indexes, and generated columns unless the function is tagged with SQLITE_INNOCUOUS. Most built-in functions are innocuous. Developers are advised to avoid using the SQLITE_INNOCUOUS flag for application-defined functions unless the function has been carefully audited and found to be free of potentially security-adverse side-effects and information-leaks.

SQLITE_SUBTYPE
The SQLITE_SUBTYPE flag indicates to SQLite that a function may call sqlite3_value_subtype() to inspect the sub-types of its arguments. Specifying this flag makes no difference for scalar or aggregate user functions. However, if it is not specified for a user-defined window function, then any sub-types belonging to arguments passed to the window function may be discarded before the window function is called (i.e. sqlite3_value_subtype() will always return 0).

See also lists of Objects, Constants, and Functions.