For most purposes, SQLite can be built just fine using the default compilation options. However, if required, the compile-time options documented below can be used to omit SQLite features (resulting in a [relfootprint | smaller compiled library size]) or to change the default values of some parameters.
Every effort has been made to ensure that the various combinations of compilation options work harmoniously and produce a working library. Nevertheless, it is strongly recommended that the SQLite test-suite be executed to check for errors before using an SQLite library built with non-standard compilation options.
$name
regsub -all "\n\\s*\n" $text "\n\n" text hd_resolve
}$text
If the HAVE_MALLOC_USABLE_SIZE option is omitted or is false, then SQLite uses a wrapper around system malloc() and realloc() that enlarges each allocation by 8 bytes and writes the size of the allocation in the initial 8 bytes, and then SQLite also implements its own home-grown version of malloc_usable_size() that consults that 8-byte prefix to find the allocation size. This approach works but it is suboptimal. Applications are encouraged to use HAVE_MALLOC_USABLE_SIZE whenever possible. } COMPILE_OPTION {HAVE_STRCHRNUL} { If the HAVE_STRCHRNUL option is true, then SQLite uses the strchrnul() library function. If this option is missing or false, then SQLite substitutes its own home-grown implementation of strchrnul(). } COMPILE_OPTION {HAVE_USLEEP} { If the HAVE_USLEEP option is true, then the default unix VFS uses the usleep() system call to implement the xSleep method. If this option is undefined or false, then xSleep on unix is implemented using sleep() which means that [sqlite3_sleep()] will have a minimum wait interval of 1000 milliseconds regardless of its argument. } COMPILE_OPTION {HAVE_UTIME} { If the HAVE_UTIME option is true, then the built-in but non-standard "unix-dotfile" VFS will use the utime() system call, instead of utimes(), to set the last access time on the lock file. }
See also: [SQLITE_OMIT_AUTOMATIC_INDEX] } COMPILE_OPTION {SQLITE_DEFAULT_AUTOVACUUM=<0 or 1 or 2>} { This macro determines if SQLite creates databases with the [auto_vacuum] flag set by default to OFF (0), FULL (1), or INCREMENTAL (2). The default value is 0 meaning that databases are created with auto-vacuum turned off. In any case the compile-time default may be overridden by the [PRAGMA auto_vacuum] command. } COMPILE_OPTION {SQLITE_DEFAULT_CACHE_SIZE=<N>} { This macro sets the default maximum size of the page-cache for each attached database. A positive value means that the limit is N page. If N is negative that means to limit the cache size to -N*1024 bytes. The suggested maximum cache size can be overridden by the [PRAGMA cache_size] command. The default value is -2000, which translates into a maximum of 2048000 bytes per cache. } COMPILE_OPTION {SQLITE_DEFAULT_FILE_FORMAT=<1 or 4>} { The default [schema format number] used by SQLite when creating new database files is set by this macro. The schema formats are all very similar. The difference between formats 1 and 4 is that format 4 understands [descending indices] and has a tighter encoding for boolean values. All versions of SQLite since 3.3.0 (2006-01-10) can read and write any schema format between 1 and 4. But older versions of SQLite might not be able to read formats greater than 1. So that older versions of SQLite will be able to read and write database files created by newer versions of SQLite, the default schema format was set to 1 for SQLite versions through 3.7.9 (2011-11-01). Beginning with version 3.7.10, the default schema format is 4. The schema format number for a new database can be set at runtime using the [PRAGMA legacy_file_format] command. } COMPILE_OPTION {SQLITE_DEFAULT_FILE_PERMISSIONS=N} { The default numeric file permissions for newly created database files under unix. If not specified, the default is 0644 which means that the files is globally readable but only writable by the creator. } COMPILE_OPTION {SQLITE_DEFAULT_FOREIGN_KEYS=<0 or 1>} { This macro determines whether enforcement of [foreign key constraints] is enabled or disabled by default for new database connections. Each database connection can always turn enforcement of foreign key constraints on and off and run-time using the [foreign_keys pragma]. Enforcement of foreign key constraints is normally off by default, but if this compile-time parameter is set to 1, enforcement of foreign key constraints will be on by default. } COMPILE_OPTION {SQLITE_DEFAULT_MMAP_SIZE=N} { This macro sets the default limit on the amount of memory that will be used for memory-mapped I/O for each open database file. If the N is zero, then memory mapped I/O is disabled by default. This compile-time limit and the [SQLITE_MAX_MMAP_SIZE] can be modified at start-time using the [sqlite3_config]([SQLITE_CONFIG_MMAP_SIZE]) call, or at run-time using the [mmap_size pragma]. } COMPILE_OPTION {SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT=<bytes>} { This option sets the size limit on [rollback journal] files in [journal_mode pragma | persistent journal mode] and [locking_mode | exclusive locking mode] and on the size of the write-ahead log file in [WAL mode]. When this compile-time option is omitted there is no upper bound on the size of the rollback journals or write-ahead logs. The journal file size limit can be changed at run-time using the [journal_size_limit pragma]. } COMPILE_OPTION {SQLITE_DEFAULT_LOCKING_MODE=<1 or 0>} { If set to 1, then the default [locking_mode] is set to EXCLUSIVE. If omitted or set to 0 then the default [locking_mode] is NORMAL. } COMPILE_OPTION {SQLITE_DEFAULT_MEMSTATUS=<1 or 0>} { This macro is used to determine whether or not the features enabled and disabled using the SQLITE_CONFIG_MEMSTATUS argument to [sqlite3_config()] are available by default. The default value is 1 ([SQLITE_CONFIG_MEMSTATUS] related features enabled). } COMPILE_OPTION {SQLITE_DEFAULT_PAGE_SIZE=<bytes>} { This macro is used to set the default page-size used when a database is created. The value assigned must be a power of 2. The default value is 4096. The compile-time default may be overridden at runtime by the [PRAGMA page_size] command. } COMPILE_OPTION {SQLITE_DEFAULT_SYNCHRONOUS=<0-3>} { This macro determines the default value of the [PRAGMA synchronous] setting. If not overridden at compile-time, the default setting is 2 (FULL). } COMPILE_OPTION {SQLITE_DEFAULT_WAL_SYNCHRONOUS=<0-3>} { This macro determines the default value of the [PRAGMA synchronous] setting for database files that open in [WAL mode]. If not overridden at compile-time, this value is the same as [SQLITE_DEFAULT_SYNCHRONOUS].
If SQLITE_DEFAULT_WAL_SYNCHRONOUS differs from SQLITE_DEFAULT_SYNCHRONOUS, and if the application has not modified the synchronous setting for the database file using the [PRAGMA synchronous] statement, then the synchronous setting is changed to value defined by SQLITE_DEFAULT_WAL_SYNCHRONOUS when the database connection switches into WAL mode for the first time. If the SQLITE_DEFAULT_WAL_SYNCHRONOUS value is not overridden at compile-time, then it will always be the same as [SQLITE_DEFAULT_SYNCHRONOUS] and so no automatic synchronous setting changes will ever occur. } COMPILE_OPTION {SQLITE_DEFAULT_WAL_AUTOCHECKPOINT=<pages>} { This macro sets the default page count for the [WAL] [checkpointing | automatic checkpointing] feature. If unspecified, the default page count is 1000. } COMPILE_OPTION {SQLITE_DEFAULT_WORKER_THREADS=N} { This macro sets the default value for the [SQLITE_LIMIT_WORKER_THREADS] parameter. The [SQLITE_LIMIT_WORKER_THREADS] parameter sets the maximum number of auxiliary threads that a single [prepared statement] will launch to assist it with a query. If not specified, the default maximum is 0. The value set here cannot be more than [SQLITE_MAX_WORKER_THREADS]. } COMPILE_OPTION {SQLITE_EXTRA_DURABLE} { The SQLITE_EXTRA_DURABLE compile-time option that used to cause the default [PRAGMA synchronous] setting to be EXTRA, rather than FULL. This option is no longer supported. Use [SQLITE_DEFAULT_SYNCHRONOUS|SQLITE_DEFAULT_SYNCHRONOUS=3] instead. } COMPILE_OPTION {SQLITE_FTS3_MAX_EXPR_DEPTH=N} { This macro sets the maximum depth of the search tree that corresponds to the right-hand side of the MATCH operator in an [FTS3] or [FTS4] full-text index. The full-text search uses a recursive algorithm, so the depth of the tree is limited to prevent using too much stack space. The default limit is 12. This limit is sufficient for up to 4095 search terms on the right-hand side of the MATCH operator and it holds stack space usage to less than 2000 bytes.
For ordinary FTS3/FTS4 queries, the search tree depth is approximately the base-2 logarithm of the number of terms in the right-hand side of the MATCH operator. However, for [phrase queries] and [NEAR queries] the search tree depth is linear in the number of right-hand side terms. So the default depth limit of 12 is sufficient for up to 4095 ordinary terms on a MATCH, it is only sufficient for 11 or 12 phrase or NEAR terms. Even so, the default is more than enough for most application. } COMPILE_OPTION {SQLITE_LIKE_DOESNT_MATCH_BLOBS} { This compile-time option causes the [LIKE] operator to always return False if either operand is a BLOB. The default behavior of [LIKE] is that BLOB operands are cast to TEXT before the comparison is done.
This compile-time option makes SQLite run more efficiently when processing queries that use the [LIKE] operator, at the expense of breaking backwards compatibility. However, the backwards compatibility break may be only a technicality. There was a long-standing bug in the [LIKE] processing logic (see [https://www.sqlite.org/src/info/05f43be8fdda9f]) that caused it to misbehavior for BLOB operands and nobody observed that bug in nearly 10 years of active use. So for more users, it is probably safe to enable this compile-time option and thereby save a little CPU time on LIKE queries.
This compile-time option affects the SQL [LIKE] operator only and has no impact on the [sqlite3_strlike()] C-language interface. } COMPILE_OPTION {SQLITE_MAX_MMAP_SIZE=N} { This macro sets a hard upper bound on the amount of address space that can be used by any single database for memory-mapped I/O. Setting this value to 0 completely disables memory-mapped I/O and causes logic associated with memory-mapped I/O to be omitted from the build. This option does change the default memory-mapped I/O address space size (set by [SQLITE_DEFAULT_MMAP_SIZE] or sqlite3_config([SQLITE_CONFIG_MMAP_SIZE]) or the run-time memory-mapped I/O address space size (set by sqlite3_file_control([SQLITE_FCNTL_MMAP_SIZE]) or [PRAGMA mmap_size]) as long as those other settings are less than the maximum value defined here. } COMPILE_OPTION {SQLITE_MAX_SCHEMA_RETRY=N} { Whenever the database schema changes, prepared statements are automatically reprepared to accommodate the new schema. There is a race condition here in that if one thread is constantly changing the schema, another thread might spin on reparses and repreparations of a prepared statement and never get any real work done. This parameter prevents an infinite loop by forcing the spinning thread to give up after a fixed number of attempts at recompiling the prepared statement. The default setting is 50 which is more than adequate for most applications. } COMPILE_OPTION {SQLITE_MAX_WORKER_THREADS=N} { Set an upper bound on the [sqlite3_limit](db,[SQLITE_LIMIT_WORKER_THREADS],N) setting that determines the maximum number of auxiliary threads that a single [prepared statement] will use to aid with CPU-intensive computations (mostly sorting). See also the [SQLITE_DEFAULT_WORKER_THREADS] options. } COMPILE_OPTION {SQLITE_MINIMUM_FILE_DESCRIPTOR=N} { The unix [VFS] will never use a file descriptor less than N. The default value of N is 3.
Avoiding the use of low-numbered file descriptors is a defense against accidental database corruption. If a database file was opened using file descriptor 2, for example, and then an assert() failed and invoked write(2,...), that would likely cause database corruption by overwriting part of the database file with the assertion error message. Using only higher-valued file descriptors avoids this potential problem. The protection against using low-numbered file descriptors can be disabled by setting this compile-time option to 0. } COMPILE_OPTION {SQLITE_POWERSAFE_OVERWRITE=<0 or 1>} { This option changes the default assumption about [powersafe overwrite] for the underlying filesystems for the unix and windows [VFSes]. Setting SQLITE_POWERSAFE_OVERWRITE to 1 causes SQLite to assume that application-level writes cannot changes bytes outside the range of bytes written even if the write occurs just before a power loss. With SQLITE_POWERSAFE_OVERWRITE set to 0, SQLite assumes that other bytes in the same sector with a written byte might be changed or damaged by a power loss. } COMPILE_OPTION {SQLITE_REVERSE_UNORDERED_SELECTS} { This option causes the [PRAGMA reverse_unordered_selects] setting to be enabled by default. When enabled, [SELECT] statements that lack an ORDER BY clause will run in reverse order.
This option is useful for detecting when applications (incorrectly) assume that the order of rows in a SELECT without an ORDER BY clause will always be the same. } COMPILE_OPTION {SQLITE_SORTER_PMASZ=N} { If multi-threaded processing is enabled via the [PRAGMA threads] setting, then sort operations will attempt to start helper threads when the amount of content to be sorted exceeds the minimum of the [cache_size] and PMA Size determined by the [SQLITE_CONFIG_PMASZ] start-time option. This compile-time option sets the default value for the [SQLITE_CONFIG_PMASZ] start-time option. The default value is 250. } COMPILE_OPTION {SQLITE_STMTJRNL_SPILL=N} { The SQLITE_STMTJRNL_SPILL compile-time option determines the default setting of the [SQLITE_CONFIG_STMTJRNL_SPILL] start-time setting. That setting determines the size threshold above which [statement journals] are moved from memory to disk. } COMPILE_OPTION {SQLITE_WIN32_MALLOC} { This option enables the use of the Windows Heap API functions for memory allocation instead of the standard library malloc() and free() routines. } COMPILE_OPTION {YYSTACKDEPTH=<max_depth>} { This macro sets the maximum depth of the LALR(1) stack used by the SQL parser within SQLite. The default value is 100. A typical application will use less than about 20 levels of the stack. Developers whose applications contain SQL statements that need more than 100 LALR(1) stack entries should seriously consider refactoring their SQL as it is likely to be well beyond the ability of any human to comprehend. }
There are compile-time options that will set upper bounds on the sizes of various structures in SQLite. The compile-time options normally set a hard upper bound that can be changed at run-time on individual [database connections] using the [sqlite3_limit()] interface.
The compile-time options for setting upper bounds are [limits | documented separately]. The following is a list of the available settings:
SQLITE_TEMP_STORE | Meaning |
---|---|
0 | Always use temporary files |
1 | Use files by default but allow the [PRAGMA temp_store] command to override |
2 | Use memory by default but allow the [PRAGMA temp_store] command to override |
3 | Always use memory |
Some future versions of SQLite may change to enable this feature by default. } COMPILE_OPTION {SQLITE_ALLOW_COVERING_INDEX_SCAN=<0 or 1>} { This C-preprocess macro determines the default setting of the [SQLITE_CONFIG_COVERING_INDEX_SCAN] configuration setting. It defaults to 1 (on) which means that covering indices are used for full table scans where possible, in order to reduce I/O and improve performance. However, the use of a covering index for a full scan will cause results to appear in a different order from legacy, which could cause some (incorrectly-coded) legacy applications to break. Hence, the covering index scan option can be disabled at compile-time on systems that what to minimize their risk of exposing errors in legacy applications. } COMPILE_OPTION {SQLITE_ENABLE_8_3_NAMES=<1 or 2>} { If this C-preprocessor macro is defined, then extra code is included that allows SQLite to function on a filesystem that only support 8+3 filenames. If the value of this macro is 1, then the default behavior is to continue to use long filenames and to only use 8+3 filenames if the database connection is opened using [URI filenames] with the "8_3_names=1" query parameter. If the value of this macro is 2, then the use of 8+3 filenames becomes the default but may be disabled on using the 8_3_names=0 query parameter. See } COMPILE_OPTION {SQLITE_ENABLE_API_ARMOR} { When defined, this C-preprocessor macro activates extra code that attempts to detect misuse of the SQLite API, such as passing in NULL pointers to required parameters or using objects after they have been destroyed. } COMPILE_OPTION {SQLITE_ENABLE_ATOMIC_WRITE} { If this C-preprocessor macro is defined and if the xDeviceCharacteristics method of [sqlite3_io_methods] object for a database file reports (via one of the [SQLITE_IOCAP_ATOMIC] bits) that the filesystem supports atomic writes and if a transaction involves a change to only a single page of the database file, then the transaction commits with just a single write request of a single page of the database and no rollback journal is created or written. On filesystems that support atomic writes, this optimization can result in significant speed improvements for small updates. However, few filesystems support this capability and the code paths that check for this capability slow down write performance on systems that lack atomic write capability, so this feature is disabled by default. } COMPILE_OPTION {SQLITE_ENABLE_COLUMN_METADATA} { When this C-preprocessor macro is defined, SQLite includes some additional APIs that provide convenient access to meta-data about tables and queries. The APIs that are enabled by this option are:
Because of security concerns, the two-argument fts3_tokenizer() feature was disabled beginning with [Version 3.11.0] unless this compile-time option is used. [Version 3.12.0] added the [sqlite3_db_config](db,[SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER],1,0) interface that activates the two-argument version of [fts3_tokenizer()] for a specific [database connection] at run-time. } COMPILE_OPTION {SQLITE_ENABLE_FTS4} { When this option is defined in the [amalgamation], versions 3 and 4 of the full-text search engine is added to the build automatically. } COMPILE_OPTION {SQLITE_ENABLE_FTS5} { When this option is defined in the [amalgamation], versions 5 of the full-text search engine ([fts5]) is added to the build automatically. } COMPILE_OPTION {SQLITE_ENABLE_ICU} { This option causes the [http://www.icu-project.org/ | International Components for Unicode] or "ICU" extension to SQLite to be added to the build. } COMPILE_OPTION {SQLITE_ENABLE_IOTRACE} { When both the SQLite core and the [Command Line Interface] (CLI) are both compiled with this option, then the CLI provides an extra command named ".iotrace" that provides a low-level log of I/O activity. This option is experimental and may be discontinued in a future release. } COMPILE_OPTION {SQLITE_ENABLE_JSON1} { When this option is defined in the [amalgamation], the [JSON SQL functions] are added to the build automatically. } COMPILE_OPTION {SQLITE_ENABLE_LOCKING_STYLE} { This option enables additional logic in the OS interface layer for Mac OS X. The additional logic attempts to determine the type of the underlying filesystem and choose and alternative locking strategy that works correctly for that filesystem type. Five locking strategies are available:
The action of the preupdate hook is similar to the [sqlite3_update_hook|update hook] except that the callback is invoked before the change, not afterwards, and the preupdate hook interfaces are omitted unless this compile-time option is used.
The preupdate hook interfaces were originally added to support the [session] extension. } COMPILE_OPTION {SQLITE_ENABLE_RBU} { Enable the code the implements the [RBU extension]. } COMPILE_OPTION {SQLITE_ENABLE_RTREE} { This option causes SQLite to include support for the [rtree | R*Tree index extension]. } COMPILE_OPTION {SQLITE_ENABLE_SESSION} { This option enables the [session extension]. } COMPILE_OPTION {SQLITE_ENABLE_STMT_SCANSTATUS} { This option enables the [sqlite3_stmt_scanstatus()] interface. The [sqlite3_stmt_scanstatus()] interface is normally omitted from the build because it imposes a small performance penalty, even on statements that do not use the feature. } COMPILE_OPTION {SQLITE_RTREE_INT_ONLY} { If this option is used together with [SQLITE_ENABLE_RTREE] then the [rtree | R*Tree extension] will only store 32-bit signed integer coordinates and all internal computations will be done using integers instead of floating point numbers. } COMPILE_OPTION {SQLITE_ENABLE_SQLLOG} { This option enables extra code (especially the [SQLITE_CONFIG_SQLLOG] option to [sqlite3_config()]) that can be used to create logs of all SQLite processing performed by an application. These logs can be useful in doing off-line analysis of the behavior of an application, and especially for performance analysis. In order for the SQLITE_ENABLE_SQLLOG option to be useful, some extra code is required. The "test_sqllog.c" source code file in the SQLite source tree is a working example of the required extra code. On unix and windows systems, a developer can append the text of the "test_sqllog.c" source code file to the end of an "sqlite3.c" amalgamation, recompile the application using the -DSQLITE_ENABLE_SQLLOG option, then control logging using environment variables. See the header comment on the "test_sqllog.c" source file for additional detail. } COMPILE_OPTION {SQLITE_ENABLE_STAT2} { This option used to cause the [ANALYZE] command to collect index histogram data in the sqlite_stat2 table. But that functionality was superceded by [SQLITE_ENABLE_STAT3] as of SQLite version 3.7.9. The SQLITE_ENABLE_STAT2 compile-time option is now a no-op. } COMPILE_OPTION {SQLITE_ENABLE_STAT3} { This option adds additional logic to the [ANALYZE] command and to the [query planner] that can help SQLite to chose a better query plan under certain situations. The [ANALYZE] command is enhanced to collect histogram data from the left-most column of each index and store that data in the [sqlite_stat3] table. The query planner will then use the histogram data to help it make better index choices. Note, however, that the use of histogram data in query planner violates the [query planner stability guarantee] which is important to some applications.
} COMPILE_OPTION {SQLITE_ENABLE_STAT4} { This option adds additional logic to the [ANALYZE] command and to the [query planner] that can help SQLite to chose a better query plan under certain situations. The [ANALYZE] command is enhanced to collect histogram data from all columns of every index and store that data in the [sqlite_stat4] table. The query planner will then use the histogram data to help it make better index choices. The downside of this compile-time option is that it violates the [query planner stability guarantee] making it more difficult to ensure consistent performance in mass-produced applications.
SQLITE_ENABLE_STAT4 is an enhancement of [SQLITE_ENABLE_STAT3]. STAT3 only recorded histogram data for the left-most column of each index whereas the STAT4 enhancement records histogram data from all columns of each index. The [SQLITE_ENABLE_STAT3] compile-time option is a no-op and is ignored if the SQLITE_ENABLE_STAT4 compile-time option is used. } COMPILE_OPTION {SQLITE_ENABLE_TREE_EXPLAIN} { This compile-time option is no longer used. } COMPILE_OPTION {SQLITE_ENABLE_UPDATE_DELETE_LIMIT} { This option enables an optional ORDER BY and LIMIT clause on [UPDATE] and [DELETE] statements.
If this option is defined, then it must also be defined when using the 'lemon' tool to generate a parse.c file. Because of this, this option may only be used when the library is built from source, not from the [amalgamation] or from the collection of pre-packaged C files provided for non-Unix like platforms on the website.
} COMPILE_OPTION {SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION} { When the SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION compile-time option is activated, SQLite will suppress "unknown function" errors when running an [EXPLAIN] or [EXPLAIN QUERY PLAN]. Instead of throwing an error, SQLite will insert a substitute no-op function named "unknown()". The substitution of "unknown()" in place of unrecognized functions only occurs on [EXPLAIN] and [EXPLAIN QUERY PLAN], not on ordinary statements.When used in the [command-line shell], the SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION feature allows SQL text that contains application-defined functions to be pasted into the shell for analysis and debugging without having to create and load an extension that implements the application-defined functions. } COMPILE_OPTION {SQLITE_ENABLE_UNLOCK_NOTIFY} { This option enables the [sqlite3_unlock_notify()] interface and its associated functionality. See the documentation titled [Using the SQLite Unlock Notification Feature] for additional information. } COMPILE_OPTION {SQLITE_SOUNDEX} { This option enables the [soundex() SQL function]. } COMPILE_OPTION {SQLITE_USE_FCNTL_TRACE} { This option causes SQLite to issue extra [SQLITE_FCNTL_TRACE] file controls to provide supplementary information to the VFS. The "vfslog.c" extension makes use of this to provide enhanced logs of VFS activity. } COMPILE_OPTION {YYTRACKMAXSTACKDEPTH} { This option causes the LALR(1) parser stack depth to be tracked and reported using the [sqlite3_status]([SQLITE_STATUS_PARSER_STACK],...) interface. SQLite's LALR(1) parser has a fixed stack depth (determined at compile-time using the [YYSTACKDEPTH] options). This option can be used to help determine if an application is getting close to exceeding the maximum LALR(1) stack depth. }
The following options can be used to [relfootprint | reduce the size of the compiled library] by omitting unused features. This is probably only useful in embedded systems where space is especially tight, as even with all features included the SQLite library is relatively small. Don't forget to tell your compiler to optimize for binary size! (the -Os option if using GCC). Telling your compiler to optimize for size usually has a much larger impact on library footprint than employing any of these compile-time options. You should also verify that debugging options are disabled.
The macros in this section do not require values. The following
compilation switches all have the same effect:
-DSQLITE_OMIT_ALTERTABLE
-DSQLITE_OMIT_ALTERTABLE=1
-DSQLITE_OMIT_ALTERTABLE=0
If any of these options are defined, then the same set of SQLITE_OMIT_* options must also be defined when using the 'lemon' tool to generate the parse.c file and when compiling the 'mkkeywordhash' tool which generates the keywordhash.h file. Because of this, these options may only be used when the library is built from canonical source, not from the [amalgamation]. Some SQLITE_OMIT_* options might work, or appear to work, when used with the [amalgamation]. But this is not guaranteed. In general, always compile from canonical sources in order to take advantage of SQLITE_OMIT_* options.
Important Note: The SQLITE_OMIT_* options may not work with the [amalgamation]. SQLITE_OMIT_* compile-time options usually work correctly only when SQLite is built from canonical source files.
Special versions of the SQLite amalgamation that do work with a predetermined set of SQLITE_OMIT_* options can be generated. To do so, make a copy of the Makefile.linux-gcc makefile template in the canonical source code distribution. Change the name of your copy to simply "Makefile". Then edit "Makefile" to set up appropriate compile-time options. Then type:
make clean; make sqlite3.cThe resulting "sqlite3.c" amalgamation code file (and its associated header file "sqlite3.h") can then be moved to a non-unix platform for final compilation using a native compiler.
The SQLITE_OMIT_* options are unsupported. By this we mean that an SQLITE_OMIT_* option that omits code from the build in the current release might become a no-op in the next release. Or the other way around: an SQLITE_OMIT_* that is a no-op in the current release might cause code to be excluded in the next release. Also, not all SQLITE_OMIT_* options are tested. Some SQLITE_OMIT_* options might cause SQLite to malfunction and/or provide incorrect answers.
Important Note: The SQLITE_OMIT_* compile-time options are unsupported.
In the future, this option may also disable other floating point functionality, for example the [sqlite3_result_double()], [sqlite3_bind_double()], [sqlite3_value_double()] and [sqlite3_column_double()] API functions.
} COMPILE_OPTION {SQLITE_OMIT_FOREIGN_KEY} { If this option is defined, then [foreign key constraint] syntax is not recognized. } COMPILE_OPTION {SQLITE_OMIT_GET_TABLE} { This option causes support for [sqlite3_get_table()] and [sqlite3_free_table()] to be omitted. } COMPILE_OPTION {SQLITE_OMIT_INCRBLOB} { This option causes support for [sqlite3_blob | incremental BLOB I/O] to be omitted. } COMPILE_OPTION {SQLITE_OMIT_INTEGRITY_CHECK} { This option omits support for the [integrity_check pragma]. } COMPILE_OPTION {SQLITE_OMIT_LIKE_OPTIMIZATION} { This option disables the ability of SQLite to use indices to help resolve [LIKE] and [GLOB] operators in a WHERE clause. } COMPILE_OPTION {SQLITE_OMIT_LOAD_EXTENSION} { This option omits the entire extension loading mechanism from SQLite, including [sqlite3_enable_load_extension()] and [sqlite3_load_extension()] interfaces. } COMPILE_OPTION {SQLITE_OMIT_LOCALTIME} { This option omits the "localtime" modifier from the date and time functions. This option is sometimes useful when trying to compile the date and time functions on a platform that does not support the concept of local time. } COMPILE_OPTION {SQLITE_OMIT_LOOKASIDE} { This option omits the [lookaside memory allocator]. } COMPILE_OPTION {SQLITE_OMIT_MEMORYDB} { When this is defined, the library does not respect the special database name ":memory:" (normally used to create an [in-memory database]). If ":memory:" is passed to [sqlite3_open()], [sqlite3_open16()], or [sqlite3_open_v2()], a file with this name will be opened or created. } COMPILE_OPTION {SQLITE_OMIT_OR_OPTIMIZATION} { This option disables the ability of SQLite to use an index together with terms of a WHERE clause connected by the OR operator. } COMPILE_OPTION {SQLITE_OMIT_PAGER_PRAGMAS} { Defining this option omits pragmas related to the pager subsystem from the build. } COMPILE_OPTION {SQLITE_OMIT_PRAGMA} { This option is used to omit the [PRAGMA] command from the library. Note that it is useful to define the macros that omit specific pragmas in addition to this, as they may also remove supporting code in other sub-systems. This macro removes the [PRAGMA] command only. } COMPILE_OPTION {SQLITE_OMIT_PROGRESS_CALLBACK} { This option may be defined to omit the capability to issue "progress" callbacks during long-running SQL statements. The [sqlite3_progress_handler()] API function is not present in the library. } COMPILE_OPTION {SQLITE_OMIT_QUICKBALANCE} { This option omits an alternative, faster B-Tree balancing routine. Using this option makes SQLite slightly smaller at the expense of making it run slightly slower. } COMPILE_OPTION {SQLITE_OMIT_REINDEX} { When this option is defined, the [REINDEX] command is not included in the library. Executing a [REINDEX] statement causes a parse error. } COMPILE_OPTION {SQLITE_OMIT_SCHEMA_PRAGMAS} { Defining this option omits pragmas for querying the database schema from the build. } COMPILE_OPTION {SQLITE_OMIT_SCHEMA_VERSION_PRAGMAS} { Defining this option omits pragmas for querying and modifying the database schema version and user version from the build. Specifically, the [schema_version] and [user_version] PRAGMAs are omitted. } COMPILE_OPTION {SQLITE_OMIT_SHARED_CACHE} { This option builds SQLite without support for shared-cache mode. The [sqlite3_enable_shared_cache()] is omitted along with a fair amount of logic within the B-Tree subsystem associated with shared cache management. } COMPILE_OPTION {SQLITE_OMIT_SUBQUERY} { If defined, support for sub-selects and the IN() operator are omitted. } COMPILE_OPTION {SQLITE_OMIT_TCL_VARIABLE} { If this macro is defined, then the special "$SQLITE_DEBUG also enables some other debugging features, such as special [PRAGMA] statements that turn on tracing and listing features used for troubleshooting and analysis of the [VDBE] and code generator. } COMPILE_OPTION {SQLITE_MEMDEBUG} { The SQLITE_MEMDEBUG option causes an instrumented [debugging memory allocator] to be used as the default memory allocator within SQLite. The instrumented memory allocator checks for misuse of dynamically allocated memory. Examples of misuse include using memory after it is freed, writing off the ends of a memory allocation, freeing memory not previously obtained from the memory allocator, or failing to initialize newly allocated memory. }
The following macros specify interface linkage for certain kinds of SQLite builds. The Makefiles will normally handle setting these macros automatically. Application developers should not need to worry with these macros. The following documentation about these macros is included completeness.
A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_CALLBACK} { This macro specifies the calling convention used by callback pointers in SQLite. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl" or "__stdcall". The "__cdecl" setting is the default, but "__stdcall" is used when SQLite is intended to be compiled as a Windows system library.
A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_CDECL} { This macro specifies the calling convention used by varargs interface routines in SQLite. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl". This macro is used on varargs routines and so cannot be set to "__stdcall" since the __stdcall calling convention does not support varargs functions.
A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_SYSCALL} { This macro identifies the calling convention used by operating system interfaces for target the platform for an SQLite build. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__stdcall".
A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_TCLAPI} { This macro specifies the calling convention used by the [http://www.tcl.tk | TCL] library interface routines. This macro is not used by the SQLite core, but only by the [TCL Interface] and [TCL test suite]. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl". This macro is used on TCL library interface routines which are always compiled as __cdecl, even on platforms that prefer to use __stdcall, so this macro should not be set to __stdcall unless the platform as a custom TCL library build that supports __stdcall.
This macro may not be used in combination with any of [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. }