Updated: 2025/Nov/16

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

SQLITE_DETERMINISTIC(3)    Library Functions Manual    SQLITE_DETERMINISTIC(3)

NAME
     SQLITE_DETERMINISTIC, SQLITE_DIRECTONLY, SQLITE_SUBTYPE,
     SQLITE_INNOCUOUS, SQLITE_RESULT_SUBTYPE - function flags

SYNOPSIS
     #include <sqlite3.h>

     #define SQLITE_DETERMINISTIC
     #define SQLITE_DIRECTONLY
     #define SQLITE_SUBTYPE
     #define SQLITE_INNOCUOUS
     #define SQLITE_RESULT_SUBTYPE

DESCRIPTION
     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 surreptitiously 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 might
             call sqlite3_value_subtype() to inspect the sub-types of its
             arguments.  This flag instructs SQLite to omit some corner-case
             optimizations that might disrupt the operation of the
             sqlite3_value_subtype() function, causing it to return zero
             rather than the correct subtype().  SQL functions that invokes
             sqlite3_value_subtype() should have this property.  If the
             SQLITE_SUBTYPE property is omitted, then the return value from
             sqlite3_value_subtype() might sometimes be zero even though a
             non-zero subtype was specified by the function argument
             expression.

     SQLITE_RESULT_SUBTYPE
             The SQLITE_RESULT_SUBTYPE flag indicates to SQLite that a
             function might call sqlite3_result_subtype() to cause a sub-type
             to be associated with its result.  Every function that invokes
             sqlite3_result_subtype() should have this property.  If it does
             not, then the call to sqlite3_result_subtype() might become a no-
             op if the function is used as term in an expression index.  On
             the other hand, SQL functions that never invoke
             sqlite3_result_subtype() should avoid setting this property, as
             the purpose of this property is to disable certain optimizations
             that are incompatible with subtypes.

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

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

SEE ALSO
     sqlite3_create_function(3), sqlite3_result_subtype(3),
     sqlite3_value_subtype(3), SQLITE_DBCONFIG_MAINDBNAME(3), SQLITE_UTF8(3)

NetBSD 11.99                   January 24, 2024                   NetBSD 11.99