1. Обзор

В большинстве целей SQLite может быть построен, очень хорошо используя параметры компиляции по умолчанию. Однако при необходимости варианты времени компиляции ниже, могут использоваться, чтобы опустить особенности SQLite (приводит к a меньшему собранному размеру библиотеки) или изменить значения по умолчанию.

Много сил приложено, чтобы гарантировать, чтобы различные комбинации параметров компиляции работали гармонично и произвели рабочую библиотеку. Тем не менее, сильно рекомендуется, чтобы набор тестов SQLite был выполнен, чтобы проверить ошибки перед использованием библиотеки SQLite, построенной с нестандартными параметрами компиляции.

2. Рекомендуемые варианты времени компиляции

Следующие варианты времени компиляции рекомендуются для приложений, которые в состоянии использовать их, чтобы минимизировать количество циклов CPU и байты памяти, используемой SQLite. Не все эти варианты времени компиляции применимы везде. Например, выбор SQLITE_THREADSAFE=0 применим только приложениями, которые никогда не используют доступ к SQLite больше, чем от одного потока за один раз. И выбор SQLITE_OMIT_PROGRESS_CALLBACK применим только приложениями, которые не используют интерфейс sqlite3_progress_handler()

Невозможно проверить каждую возможную комбинацию параметров времени компиляции для SQLite. Но следующий набор вариантов времени компиляции это одна конфигурация, которая всегда полностью проверяется.

1. SQLITE_DQS=0. Это отключает двойное цитирование строковых литералов.

2. SQLITE_THREADSAFE=0. Установка -DSQLITE_THREADSAFE=0 заставляет все mutex и логику потокобезопасности в SQLite быть опущенными. Это единственные причины выбора времени компиляции SQLite, чтобы работать приблизительно на 2% быстрее и также уменьшает размер библиотеки приблизительно на 2%. Но оборотная сторона то, что использование выбора времени компиляции означает, что SQLite никогда не может использовать больше, чем единственный поток за один раз, даже если у каждого потока есть свое собственное соединение с базой данных.

3. SQLITE_DEFAULT_MEMSTATUS=0.Это урегулирование вызывает интерфейсы sqlite3_status(), которые отслеживают использование памяти, которое будет отключено. Это помогает sqlite3_malloc() работать намного быстрее, и так как SQLite использует sqlite3_malloc() внутренне, это помогает сделать всю библиотеку быстрее.

4. SQLITE_DEFAULT_WAL_SYNCHRONOUS=1. Для максимальной безопасности базы данных после потерь питания рекомендуется установить PRAGMA synchronous=FULL . Однако, в режиме WAL полная целостность БД гарантируется с PRAGMA synchronous=NORMAL. С PRAGMA synchronous=NORMAL в режиме WAL недавние изменения базы данных могли бы быть отменены потерями питания, но база данных не будет испорчена. Кроме того, транзакции передаются намного быстрее в режиме WAL, используя synchronous=NORMAL, чем с synchronous=FULL по умолчанию. По этим причинам рекомендуется, чтобы синхронные настройки были изменены от FULL до NORMAL, переключаясь в режим WAL. Этот выбор времени компиляции достигнет этого.

5. SQLITE_LIKE_DOESNT_MATCH_BLOBS. Исторически, SQLite позволил операнды BLOB операторам LIKE и GLOB. Но имея BLOB как операнд LIKE или GLOB усложняет и замедляет оптимизацию LIKE. Когда этот выбор установлен, это означает, что LIKE и операторы GLOB всегда возвращают FALSE, если любой операнд BLOB. Это упрощает оптимизацию LIKE и позволяет ускорить запросы, которые используют оптимизацию LIKE.

6. SQLITE_MAX_EXPR_DEPTH=0 .Урегулирование максимальной глубины дерева синтаксического анализа выражения к нолю отключает всю проверку глубины дерева синтаксического анализа выражения, которая упрощает код, приводящий к более быстрому выполнению, и помогает дереву синтаксического анализа использовать меньше памяти.

7. SQLITE_OMIT_DECLTYPE. Опуская (редко необходимую) способность возвратить заявленный тип колонок от набора результатов запроса, подготовленные запросы могут быть потреблять меньше памяти.

8. SQLITE_OMIT_DEPRECATED . Исключение устаревших интерфейсов и особенностей не поможет SQLite работать немного быстрее. Это уменьшит издержки библиотеки, как бы то ни было. И это правильный поступок.

9. SQLITE_OMIT_PROGRESS_CALLBACK. Счетчик отзыва обработчика прогресса должен быть проверен во внутреннем цикле движка байт-кода. Опуская этот интерфейс, единственное условное предложение удалено из внутреннего цикла движка байт-кода, помогая SQL-операторам работать немного быстрее.

10. SQLITE_OMIT_SHARED_CACHE. Исключение возможности использования общего кэша позволяет многим условным предложениям в критических по отношению к работе разделах кода быть устраненными. Это может дать значимое улучшение работы.

11. SQLITE_USE_ALLOCA. Используйте alloca(), чтобы динамично ассигновать временное стековое пространство для использования в единственной функции на системах, которые поддерживают alloca(). Без этого выбора временное место выделено из кучи.

12. SQLITE_OMIT_AUTOINIT. Библиотека SQLite должна быть инициализирована, используя sqlite3_initialize() прежде чем определенные интерфейсы будут использоваться. Эта инициализация обычно происходит автоматически в первый раз, когда она необходима. Однако с выбором SQLITE_OMIT_AUTOINIT, автоматическая инициализация опущена. Это помогает многим вызовам API работать немного быстрее (так как они не должны проверять, произошла ли инициализация), но это также означает, что приложение должно вызвать sqlite3_initialize() явно. Если SQLite будет собран с -DSQLITE_OMIT_AUTOINIT и sqlite3_malloc(), sqlite3_vfs_find() или sqlite3_open() вызван без первого запроса sqlite3_initialize(), вероятным результатом будет segfault.

Когда все рекомендуемые варианты времени компиляции выше будут использоваться, библиотека SQLite будет приблизительно на 3% меньшей и использовать приблизительно на 5% меньше циклов CPU. Таким образом, эти варианты не имеют огромного значения. Но в некоторых ситуациях с дизайном, каждый немного помогает.

3. Конфигурация платформы

_HAVE_SQLITE_CONFIG_H

Если макрос _HAVE_SQLITE_CONFIG_H определен, исходный код SQLite будет делать попытку #include файла "config.h". Файл "config.h" обычно содержит другие параметры конфигурации, особенно варианты типа "HAVE_INTERFACE", произведенные скриптами autoconf.

HAVE_FDATASYNC

Если HAVE_FDATASYNC = true, то VFS по умолчанию для систем Unix попытается использовать fdatasync() вместо fsync() в соответствующих случаях. Если этот флаг отсутствует или false, fsync() всегда используется.

HAVE_GMTIME_R

Если HAVE_GMTIME_R = true и если SQLITE_OMIT_DATETIME_FUNCS = true, CURRENT_TIME, CURRENT_DATE и CURRENT_TIMESTAMP будут использовать ориентированное на многопотоковое исполнение "gmtime_r()" вместо "gmtime()". В обычном случае, где SQLITE_OMIT_DATETIME_FUNCS не определяется или false, встроенные функции даты и времени используются, чтобы осуществить ключевые слова CURRENT_TIME, CURRENT_DATE и CURRENT_TIMESTAMP, не вызывая gmtime_r() или gmtime().

HAVE_ISNAN

Если HAVE_ISNAN = true, SQLite вызывает системную функцию isnan(), чтобы определить, является ли значение с плавающей точкой двойной точности NaN. Если HAVE_ISNAN не определен или false, SQLite заменяет своим собственным отечественным внедрением isnan().

HAVE_LOCALTIME_R

Если HAVE_LOCALTIME_R = true, SQLite использует ориентированный на многопотоковое исполнение localtime_r() вместо localtime(), чтобы помочь осуществить модификатор localtime встроенным функциям даты и времени.

HAVE_LOCALTIME_S

Если HAVE_LOCALTIME_S = true, SQLite использует ориентированный на многопотоковое исполнение localtime_s() вместо localtime(), чтобы помочь осуществить модификатор localtime встроенным функциям даты и времени.

HAVE_MALLOC_USABLE_SIZE

Если HAVE_MALLOC_USABLE_SIZE = true, SQLite использует интерфейс malloc_usable_size(), чтобы найти размер выделения памяти, полученной из стандартного вызова malloc() или realloc(). Этот выбор применим только, если стандартный malloc(). На Apple "zone malloc" используется вместо этого, таким образом, этот выбор неприменим. И, конечно, если приложение поставляет свое собственное внедрение malloc, используя SQLITE_CONFIG_MALLOC, этот выбор не имеет никакого эффекта.

Если HAVE_MALLOC_USABLE_SIZE отсутствует или false, SQLite использует обертку вокруг системных malloc() и realloc(), которая увеличивает каждое распределение на 8 байтов и пишет размер распределения в начальные 8 байт, затем SQLite также осуществляет свою собственную версию malloc_usable_size(), которая работает с тем 8-байтовым префиксом, чтобы найти размер распределения. Этот подход работает, но это не оптимально. Приложения поощряются использовать HAVE_MALLOC_USABLE_SIZE, когда это возможно.

HAVE_STRCHRNUL

Если HAVE_STRCHRNUL = true, SQLite использует библиотечную функцию strchrnul(). Если этот выбор отсутствует или false, SQLite заменяет своим собственным strchrnul().

HAVE_UTIME

Если HAVE_UTIME = true, то встроенный, но нестандартный "unix-dotfile" VFS будет использовать системный вызов utime() вместо utimes(), чтобы установить последнее время доступа на файле блокировки.

SQLITE_BYTEORDER=(0|1234|4321)

SQLite должен знать, является ли родной порядок байтов целевого CPU порядком байтов big-endian или little-ending. Препроцессор SQLITE_BYTEORDER установлен в 4321 для машин с big-endian, в 1234 для little-endian или 0, чтобы означать, что порядок байтов должен быть определен во времени выполнения. Есть #ifdefs в коде, которые устанавливают SQLITE_BYTEORDER автоматически для всех общих платформ и компиляторов. Однако может быть выгодно установить SQLITE_BYTEORDER соответственно, собирая SQLite для конкретных целей. Если целевой порядок байтов не может быть определен во время компиляции, то SQLite отступает к выполнению проверок на этапе выполнения, которые всегда работают, хотя с маленькой потерей производительности.

4. Варианты установки значения параметров по умолчанию

SQLITE_DEFAULT_AUTOMATIC_INDEX=<0 или 1>

Этот макрос определяет начальное значение PRAGMA automatic_index для недавно открытых соединений с базой данных . Для всех версий от SQLite до 3.7.17, автоматические индексы обычно позволяются для новых соединений с базой данных, если этот выбор времени компиляции опущен. Однако это могло бы измениться в будущих выпусках SQLite.

См. также:: SQLITE_OMIT_AUTOMATIC_INDEX

SQLITE_DEFAULT_AUTOVACUUM=<0, 1 или 2>

Этот макрос определяет, создает ли SQLite базы данных с флагом auto_vacuum, установленным по умолчанию в OFF (0), FULL (1) или INCREMENTAL (2). Значение по умолчанию 0 подразумевает, что базы данных создаются с выключенным автовакуумом. В любом случае умолчание времени компиляции может быть отвергнуто PRAGMA auto_vacuum.

SQLITE_DEFAULT_CACHE_SIZE=<N>

Этот макрос устанавливает размер максимума по умолчанию кэша страницы для каждой добавленной базы данных. Положительное значение означает, что предел N страниц. Если N отрицателен, это означает ограничивать размер кэша в -N*1024 байт. Предложенный максимальный размер кэша может быть отвергнут PRAGMA cache_size. Значение по умолчанию -2000 переводит максимум в 2048000 байтов на кэш.

SQLITE_DEFAULT_FILE_FORMAT=<1 или 4>

Номер формата схемы по умолчанию, используемое SQLite, когда создание новых файлов базы данных установлено этим макросом. Форматы схемы все очень похожи. Различие между форматами 1 и 4 в том, что формат 4 понимает спускающиеся индексы и имеет более жесткое кодирование для булевых значений.

Все версии SQLite с 3.3.0 (2006-01-10) могут прочитать и написать любой формат схемы между 1 и 4. Но более старые версии SQLite не могли бы быть в состоянии прочитать форматы, больше 1. Чтобы более старые версии SQLite были в состоянии прочитать и написать файлы базы данных, созданные более новыми версиями SQLite, формат схемы по умолчанию был установлен в 1 для версий SQLite до 3.7.9 (2011-11-01). С version 3.7.10 (2012-01-16), формат схемы по умолчанию равняется 4.

Номер формата схемы для новой базы данных может быть определен во время выполнения, используя PRAGMA legacy_file_format.

SQLITE_DEFAULT_FILE_PERMISSIONS=N

Числовые разрешения файла по умолчанию для созданных файлов базы данных под Unix. Если не определено, 0644, что означает, что файлы глобально читаемые, но перезаписываемые только создателем.

SQLITE_DEFAULT_FOREIGN_KEYS=<0 или 1>

Этот макрос определяет, позволено ли осуществление ограничений внешнего ключа по умолчанию для новых соединений с базой данных. Каждое соединение с базой данных может всегда включить осуществление ограничений внешнего ключа во время выполнения, используя foreign_keys pragma. Осуществление ограничений внешнего ключа обычно выключено по умолчанию, но если этот параметр времени компиляции будет установлен в 1, осуществление ограничений внешнего ключа будет включено по умолчанию.

SQLITE_DEFAULT_MMAP_SIZE=N

Этот макрос устанавливает предел по умолчанию для объема памяти, который будет использоваться для I/O с отображенной памятью для каждого открытого файла базы данных. Если N = 0, I/O с отображенной памятью отключен по умолчанию. Этот предел времени компиляции и SQLITE_MAX_MMAP_SIZE могут быть изменены во время запуска, используя sqlite3_config( SQLITE_CONFIG_MMAP_SIZE), или во время выполнения, используя mmap_size pragma.

SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT=<bytes>

Этот выбор устанавливает предел размера для файлов журнала обратной перемотки в постоянном режиме журнала и режиме исключительной блокировки , а также размер файла журнала с упреждающей записью в режиме WAL. Когда этот выбор времени компиляции опущен, нет никакой верхней границы размера журнала обратной перемотки или журналов с упреждающей записью. Предел размера файла журнала может быть изменен во время выполнения, используя journal_size_limit pragma .

SQLITE_DEFAULT_LOCKING_MODE=<1 или 0>

Если установлено в 1, то умолчание для locking_mode = EXCLUSIVE. Если опущено или установлено в 0 тогда умолчание для locking_mode = NORMAL.

SQLITE_DEFAULT_LOOKASIDE=SZ,N

Устанавливает размер по умолчанию пула памяти распределителя памяти к N записям по SZ байт каждая. Это может быть изменено во время запуска, используя sqlite3_config( SQLITE_CONFIG_LOOKASIDE) и/или когда каждое соединение с базой данных открыто, используя sqlite3_db_config(db, SQLITE_DBCONFIG_LOOKASIDE).

SQLITE_DEFAULT_MEMSTATUS=<1 или 0>

Этот макрос используется, чтобы определить, позволили ли особенности и отключили использование аргумента SQLITE_CONFIG_MEMSTATUS для sqlite3_config(), доступного по умолчанию. Значение по умолчанию равняется 1 ( SQLITE_CONFIG_MEMSTATUS включен).

sqlite3_memory_used() и sqlite3_memory_highwater(), sqlite3_status64( SQLITE_STATUS_MEMORY_USED) и выбор времени компиляции SQLITE_MAX_MEMORY все нефункциональны, когда отслеживание использования памяти отключено.

SQLITE_DEFAULT_PCACHE_INITSZ=N

Этот макрос определяет число страниц, первоначально ассигнованных модулем кэша страницы, когда параметр конфигурации SQLITE_CONFIG_PAGECACHE не использован, и память для кэша страницы получена из sqlite3_malloc(). Число страниц, установленных этим макросом, ассигнуется в единственном распределении, которое уменьшает нагрузку на распределитель памяти.

SQLITE_DEFAULT_PAGE_SIZE=<bytes>

Этот макрос используется, чтобы установить размер страницы по умолчанию, используемый, когда база данных создается. Назначенное значение должно быть степенью 2. Значение по умолчанию 4096. Умолчание времени компиляции может быть отвергнуто во время выполнения через PRAGMA page_size.

SQLITE_DEFAULT_SYNCHRONOUS=<0-3>

Этот макрос определяет значение по умолчанию PRAGMA synchronous. Если не отвергнуто во время компиляции, настройка по умолчанию 2 (FULL).

SQLITE_DEFAULT_WAL_SYNCHRONOUS=<0-3>

Этот макрос определяет значение по умолчанию PRAGMA synchronous для файлов базы данных, которые открываются в режиме WAL. Если не отвергнуто во время компиляции, это значение совпадает с SQLITE_DEFAULT_SYNCHRONOUS.

Если SQLITE_DEFAULT_WAL_SYNCHRONOUS отличается от SQLITE_DEFAULT_SYNCHRONOUS, и если приложение не изменило синхронное урегулирование для файла базы данных, используя PRAGMA synchronous, то синхронные настройки изменяются к значению, определенному SQLITE_DEFAULT_WAL_SYNCHRONOUS, когда соединение с базой данных переключается в режим WAL впервые. Если SQLITE_DEFAULT_WAL_SYNCHRONOUS не будет отвергнута во время компиляции, то оно будет всегда совпадать с SQLITE_DEFAULT_SYNCHRONOUS и таким образом, никакие автоматические синхронные изменения урегулирования никогда не будут происходить.

SQLITE_DEFAULT_WAL_AUTOCHECKPOINT=<pages>

Этот макрос задает счетчик страниц по умолчанию для автоматической контрольной точки WAL. Если не указан, количество страниц по умолчанию 1000.

SQLITE_DEFAULT_WORKER_THREADS=N

Этот макрос задает значение по умолчанию для параметра SQLITE_LIMIT_WORKER_THREADS. SQLITE_LIMIT_WORKER_THREADS задает максимальное число вспомогательных потоков, которые единственный подготовленный запрос начнет. Если не определено, максимум по умолчанию 0. Значение здесь не может быть больше SQLITE_MAX_WORKER_THREADS .

SQLITE_DQS=N

Этот макрос определяет значения по умолчанию для SQLITE_DBCONFIG_DQS_DDL и SQLITE_DBCONFIG_DQS_DML, которые в свою очередь определяют, как SQLite обращается с каждым строковым литералом в двойных кавычках. Имя "DQS" обозначает "Double-Quoted String". N может быть integer 0, 1, 2 или 3.

SQLITE_DQS	Позволенные значения Double-Quoted Strings		Замечания
	В DDL	В DML
3	yes	yes	Умолчание
2	yes	no
1	no	yes
0	no	no	Рекомендуется

Рекомендуемое урегулирование 0, означает, что строковые литералы в двойных кавычках отвергнуты во всех контекстах. Однако, настройка по умолчанию 3 для максимальной совместимости с унаследованными приложениями.

SQLITE_EXTRA_DURABLE

Выбор времени компиляции SQLITE_EXTRA_DURABLE, который раньше заставлял умолчание PRAGMA synchronous быть EXTRA, а не FULL. Этот выбор больше не поддерживается. Используйте SQLITE_DEFAULT_SYNCHRONOUS=3.

SQLITE_FTS3_MAX_EXPR_DEPTH=N

Этот макрос устанавливает максимальную глубину дерева поиска, которое соответствует правой стороне оператора MATCH в полнотекстовом индексе FTS3 или FTS4. Полнотекстовый поиск использует рекурсивный алгоритм, таким образом, глубина дерева ограничивается, чтобы предотвратить использование слишком большого стекового пространства. Предел по умолчанию равняется 12. Этот предел достаточен максимум для 4095 критериев поиска на правой стороне оператора MATCH, и он держит использование стекового пространства меньше 2000 байт.

Для обычных запросов FTS3/FTS4 глубина дерева поиска это приблизительно двоичный логарифм количества условий в правой стороне оператора MATCH. Однако, для запросов фразы и запросов NEAR глубина дерева поиска линейна в количестве правых терминов стороны. Таким образом, предел глубины по умолчанию 12 достаточен максимум для 4095 обычных условий на MATCH, но это достаточно только для 11 или 12 фраз или NEAR. Несмотря на это, умолчание более чем достаточно для большей части применения.

SQLITE_LIKE_DOESNT_MATCH_BLOBS

Этот выбор времени компиляции заставляет оператор LIKE всегда возвращать False, если любой операнд BLOB. Поведение по умолчанию LIKE состоит в том, что операнды BLOB приведены к TEXT прежде, чем сравнение будет сделано.

Этот выбор времени компиляции делает SQLite управляемым более эффективно, обрабатывая запросы, которые используют оператор LIKE, за счет обратной совместимости. Однако, разрыв совместимости может быть только технической особенностью. Была давняя ошибка в логике обработки LIKE (см. https://www.sqlite.org/src/info/05f43be8fdda9f) который вызвал его для операндов BLOB, и никто не заметил ошибку почти за 10 лет активного использования. Таким образом для большего количества пользователей, вероятно, безопасно позволить этот выбор времени компиляции и таким образом сэкономить немного процессорного времени на запросах LIKE.

Этот выбор времени компиляции затрагивает только оператор SQL LIKE и не оказывает влияния на sqlite3_strlike().

SQLITE_MAX_MEMORY=N

Этот выбор ограничивает общую сумму памяти, которую SQLite будет просить от malloc() до N байт. Любая попытка SQLite, чтобы ассигновать новую память, которая первысила бы сумму всех выделений в N байт, приведет к ошибке памяти. Это жесткий верхний предел. См. также sqlite3_soft_heap_limit().

Этот предел функционален только, если статистические данные использования памяти доступны через sqlite3_memory_used() и sqlite3_status64 ( SQLITE_STATUS_MEMORY_USED). Без той информации об использовании памяти у SQLite нет способа знать, когда это собирается перейти предел, и таким образом неспособно предотвратить избыточное выделение памяти. Отслеживание использования памяти включено по умолчанию, но может быть отключено во время компиляции используя SQLITE_DEFAULT_MEMSTATUS, или во время запуска, используя sqlite3_config( SQLITE_CONFIG_MEMSTATUS).

SQLITE_MAX_MMAP_SIZE=N

Этот макрос устанавливает жесткую верхнюю границу суммы адресного пространства, которое может использоваться любой единой базой данных для I/O с отображенной памятью. Устанавливание этого значения к 0 полностью отключает I/O с отображенной памятью и заставляет не собирать логику, связанную с I/O с отображенной памятью. Этот выбор действительно изменяет размер адресного пространства I/O с отображенной памятью по умолчанию (установленный SQLITE_DEFAULT_MMAP_SIZE или sqlite3_config( SQLITE_CONFIG_MMAP_SIZE) или размер адресного пространства I/O с отображенной памятью во время выполнения (установленный sqlite3_file_control( SQLITE_FCNTL_MMAP_SIZE) или PRAGMA mmap_size) поскольку те другие параметры настройки меньше, чем максимальное значение, определенное здесь.

SQLITE_MAX_SCHEMA_RETRY=N

Каждый раз, когда схема базы данных изменяется, подготовленные запросы автоматически переподготовлены, чтобы приспособить новую схему. Есть состояние состязания здесь в том, что, если один поток постоянно изменяет схему, другой мог бы зациклиться на переразборах и переприготовлениях подготовленного запроса и никогда не получать реальную сделанную работу. Этот параметр предотвращает бесконечный цикл, вынуждая зацикленный поток сдаться после постоянного числа попыток перекомпилирования подготовленного запроса. Настройка по умолчанию равняется 50, который более, чем достаточен для большинства запросов.

SQLITE_MAX_WORKER_THREADS=N

Установите верхнюю границу sqlite3_limit(db, SQLITE_LIMIT_WORKER_THREADS,N), которая определяет максимальное количество вспомогательных потоков, которые единственный подготовленный запрос будет использовать, чтобы помочь с интенсивными вычислениями CPU (главным образом сортировкой). См. также: SQLITE_DEFAULT_WORKER_THREADS.

SQLITE_MEMDB_DEFAULT_MAXSIZE=N

Установите предел размера по умолчанию (в байтах) для баз данных в памяти, созданных, используя sqlite3_deserialize() . Это просто умолчание. Предел может быть изменен во время запуска, используя sqlite3_config( SQLITE_CONFIG_MEMDB_MAXSIZE,N) или во время выполнения для отдельных баз данных, используя SQLITE_FCNTL_SIZE_LIMIT file-control. Если никакое умолчание не определяется, используется 1073741824.

SQLITE_MINIMUM_FILE_DESCRIPTOR=N

unix VFS никогда не будет использовать дескриптор файла меньше N. По умолчанию N = 3.

Предотвращение использования дескрипторов файлов с низким номером является защитой против случайного повреждения базы данных. Если файл базы данных был открыт, используя дескриптор файла, например, 2 и затем assert() сбойнул и вызвал write(2,...), который, вероятно, вызвал бы повреждение базы данных, переписав часть файла базы данных сообщением об ошибке утверждения. Использование только дескрипторов файлов с более высоким номером избегает этой потенциальной проблемы. Защита от использования дескрипторов файлов с низким номером может быть отключена, установив этот выбор времени компиляции в 0.

SQLITE_POWERSAFE_OVERWRITE=<0 или 1>

Этот выбор изменяет предположение по умолчанию о безопасной перезаписи для основных файловых систем для Unix и windows VFS. SQLITE_POWERSAFE_OVERWRITE = 1 предписывает SQLite, чтобы предположить, что уровень приложения не может изменить байты вне диапазона записанных байтов, даже если запись происходит незадолго до потери питания. При SQLITE_POWERSAFE_OVERWRITE = 0 SQLite предполагает, что другие байты в том же самом секторе с записанным байтом могли бы быть изменены или повреждены потерями питания.

SQLITE_PRINTF_PRECISION_LIMIT=N

Этот выбор ограничивает максимальную ширину и точность замен в SQL-функции printf() и других функций форматирования строк C, такие как sqlite3_mprintf() и sqlite3_str_appendf(). Это может препятствовать тому, чтобы враждебный или работающий со сбоями скрипт использовал чрезмерную память, вызывая формат, такой как: "printf('%*s',2147483647,'hi')". N около 100000 обычно достаточно.

SQL-функция printf() подвергается пределу SQLITE_LIMIT_LENGTH в sqlite3_limit(). Следовательно, любой результат printf() с шириной или точностью больше, чем SQLITE_LIMIT_LENGTH вызовет ошибку SQLITE_TOOBIG. Однако низкоуровневое форматирование для printf() сделано подпрограммой, у которой нет доступа к SQLITE_LIMIT_LENGTH. Таким образом, форматирование низкого уровня сделано в выделении памяти, которое могло бы быть значительно больше, чем SQLITE_LIMIT_LENGTH, и проверка SQLITE_LIMIT_LENGTH выполняются только после того, как все форматирование завершено. Таким образом мог бы быть переходный буфер, который превышает SQLITE_LIMIT_LENGTH. Выбор SQLITE_PRINTF_PRECISION_LIMIT это дополнительная проверка, которая предотвращает избыточные размеры для переходного буфера, используемого в низкоуровневой подпрограмме форматирования до проверки SQLITE_LIMIT_LENGTH. function is done by a subroutine that does not

Бойтесь устанавливать SQLITE_PRINTF_PRECISION_LIMIT слишком низко. SQLite использует свой встроенный printf(), чтобы отформатировать текст запросов CREATE в таблице sqlite_schema. SQLITE_PRINTF_PRECISION_LIMIT должен быть, по крайней мере, столь же большим как самая большая таблица, индекс, представление или триггер, с которым вы, вероятно, столкнетесь.

Никакая ошибка не поднята, если ширина или точность превышают SQLITE_PRINTF_PRECISION_LIMIT. Вместо этого большая ширина или точность тихо усечены.

По умолчанию SQLITE_PRINTF_PRECISION_LIMIT = 2147483647 (0x7fffffff).

SQLITE_QUERY_PLANNER_LIMIT=N

Как часть процесса планирования запроса, SQLite перечисляет все применимые комбинации ограничений оператора Where и индексов. Для определенных патологических запросов количество этих комбинаций индекса-и-ограничения может быть очень большим, приведя к медленной работе планировщиком запроса. SQLITE_QUERY_PLANNER_LIMIT (вместе со связанным SQLITE_QUERY_PLANNER_LIMIT_INCR) ограничивает количество комбинаций индекса-и-ограничения, которые рассмотрит планировщик запроса, чтобы препятствовать тому, чтобы планировщик запроса использовал избыточное процессорное время. Значение по умолчанию для SQLITE_QUERY_PLANNER_LIMIT установлено достаточно высоко так, чтобы никогда не было достигнуто реальными запросами. Ограничение поиска планировщика запроса относится только к запросам, которые сознательно обрабатываются, чтобы использовать избыточное время планирования.

SQLITE_QUERY_PLANNER_LIMIT_INCR=N

SQLITE_QUERY_PLANNER_LIMIT задает начальное значение основания для максимального количества комбинаций индекса-и-ограничения, которые рассматривает планировщик запроса. Предел планировщика запроса увеличен SQLITE_QUERY_PLANNER_LIMIT_INCR до обработки каждой таблицы соединения так, чтобы каждая таблица будет в состоянии предложить, по крайней мере, некоторые комбинации индекса-и-ограничения оптимизатору, даже если предшествующие таблицы соединения исчерпали предел основания. Значение по умолчанию для этого выбора времени компиляции и для выбора SQLITE_QUERY_PLANNER_LIMIT установлено достаточно высоко так, чтобы они никогда не достигались реальными запросами.

SQLITE_REVERSE_UNORDERED_SELECTS

Этот выбор заставляет PRAGMA reverse_unordered_selects быть позволенным по умолчанию. Когда позволено, SELECT без ORDER BY будут выполнены в обратном порядке. Этот выбор полезен для обнаружения, когда запросы (неправильно) предполагают, что порядок строк в SELECT без пункта ORDER BY всегда будет тем же самым.

SQLITE_SORTER_PMASZ=N

Если многопоточная обработка будет позволена через PRAGMA threads, операции по сортировке попытаются начать потоки помощника, когда сумма содержания, которое будет сортировано, превысит минимум cache_size и PMA Size, определенного выбором времени запуска SQLITE_CONFIG_PMASZ. Этот выбор времени компиляции устанавливает значение по умолчанию для выбора времени запуска SQLITE_CONFIG_PMASZ. По умолчанию 250.

SQLITE_STMTJRNL_SPILL=N

SQLITE_STMTJRNL_SPILL определяет настройку по умолчанию SQLITE_CONFIG_STMTJRNL_SPILL при запуске. Это определяет порог размера, выше которого журналы запросов перемещены из памяти на диск.

SQLITE_WIN32_MALLOC

Этот выбор позволяет использование Windows Heap API для выделения памяти вместо стандартных malloc() и free().

YYSTACKDEPTH=<max_depth>

Этот макрос устанавливает максимальную глубину стека LALR(1), используемого анализатором SQL в SQLite. Значение по умолчанию 100. Типовое приложение будет использовать меньше, чем приблизительно 20 уровней стека. Разработчики, запросы которых содержат SQL-операторы, для которых нужны больше 100 записей стека LALR(1), должны серьезно рассмотреть рефакторинг их SQL.

5. Варианты установки пределов размера

Есть варианты времени компиляции, которые установят верхние границы на размерах различных структур в SQLite. Варианты времени компиляции обычно устанавливают жесткую верхнюю границу, которая может быть изменена во время выполнения на отдельных соединениях с базой данных через sqlite3_limit().

Возможности времени компиляции для урегулирования верхних границ рассмотрены отдельно. Ниже представлен список доступных параметров настройки:

• SQLITE_MAX_ATTACHED
• SQLITE_MAX_COLUMN
• SQLITE_MAX_COMPOUND_SELECT
• SQLITE_MAX_EXPR_DEPTH
• SQLITE_MAX_FUNCTION_ARG
• SQLITE_MAX_LENGTH
• SQLITE_MAX_LIKE_PATTERN_LENGTH
• SQLITE_MAX_PAGE_COUNT
• SQLITE_MAX_SQL_LENGTH
• SQLITE_MAX_VARIABLE_NUMBER

6. Варианты, чтобы управлять рабочими характеристиками

SQLITE_4_BYTE_ALIGNED_MALLOC

На большинстве систем malloc() возвращает буфер, который выровнен с 8-байтовой границей. Но на некоторых системах (например, windows) malloc() возвращает указатель, выровненный на 4 байта. Этот выбор времени компиляции должен использоваться на системах, которые возвращают такие указатели из malloc().

SQLITE_CASE_SENSITIVE_LIKE

Если этот выбор будет присутствовать, то встроенный оператор LIKE будет чувствительным к регистру. Этот же эффект может быть достигнут во время выполнения, используя case_sensitive_like pragma.

SQLITE_DIRECT_OVERFLOW_READ

Когда этот выбор присутствует, содержание в страницах переполнения файла базы данных, прочитано непосредственно с диска, обойдя кэш страницы, во время транзакций чтения. В приложениях, которые читают много больших BLOB, этот выбор мог бы улучшить производительность чтения.

SQLITE_HAVE_ISNAN

Если этот выбор будет присутствовать, то SQLite будет использовать isnan() из системной математической библиотеки. Это псевдоним для параметра конфигурации HAVE_ISNAN.

SQLITE_MAX_ALLOCATION_SIZE=N

Этот выбор времени компиляции устанавливает верхнюю границу размера выделений памяти, которую можно требовать, используя sqlite3_malloc64(), sqlite3_realloc64() и аналоги. По умолчанию 2,147,483,390 (0x7ffffeff) и это нужно считать верхней границей. Большинство запросов может обойтись максимальным размером распределения в несколько миллионов байтов.

Это ограничение на максимальный размер любого единственного выделения памяти. Это не ограничение на общую сумму ассигнованной памяти.

Сокращение максимального размера отдельных выделений памяти обеспечивает дополнительную защиту против атак "отказ в обслуживании". Это также дополнительный слой защиты против прикладных ошибок, где размер выделения памяти вычисляется, используя signed 32-bit integer, которое могло переполниться небольшим максимальным размером распределения.

SQLITE_OS_OTHER=<0 или 1>

Выбор заставляет SQLite опускать свои встроенные интерфейсы операционной системы для Unix, Windows и OS/2. У получающейся библиотеки не будет интерфейса операционной системы по умолчанию. Запросы должны использовать sqlite3_vfs_register(), чтобы зарегистрировать соответствующий интерфейс перед использованием SQLite. Запросы должны также поставлять внедрения для sqlite3_os_init() и sqlite3_os_end(). Обычная практика для поставляемого sqlite3_os_init() это вызвать sqlite3_vfs_register(). SQLite автоматически вызовет sqlite3_os_init() при запуске.

Этот выбор, как правило, используется, строя SQLite для платформы с специльной операционной системой.

SQLITE_SECURE_DELETE

Этот выбор времени компиляции изменяет настройку по умолчанию secure_delete pragma. Когда этот выбор не используется, по умолчанию secure_delete = off. Когда этот выбор присутствует, по умолчанию secure_delete defaults = on.

secure_delete предписывает переписаит нолями удаленное содержание. Есть маленькая потеря производительности, так как дополнительный I/O должен произойти. С другой стороны, secure_delete может препятствовать тому, чтобы фрагменты уязвимой информации задержались в неиспользованных частях файла базы данных после того, как это было удалено. См. документацию относительно secure_delete pragma.

SQLITE_THREADSAFE=<0, 1 или 2>

Этот выбор управляет, включен ли код в SQLite, чтобы позволить ему работать безопасно в многопоточной окружающей среде. Умолчание: SQLITE_THREADSAFE=1, который безопасен для использования в многопоточной окружающей среде. Когда собрано с SQLITE_THREADSAFE=0, весь код mutexing опущен, и небезопасно использовать SQLite в многопоточной программе. Когда собрано с SQLITE_THREADSAFE=2, SQLite может использоваться в многопоточной программе, пока никакие два потока не пытаются использовать то же самое соединение с базой данных (или любые подготовленные запросы, полученные из того соединения с базой данных) в то же время.

Чтобы работать иначе, SQLITE_THREADSAFE=1 устанавливает по умолчанию threading mode в Serialized. SQLITE_THREADSAFE=2 устанавливает по умолчанию threading mode в Multi-threaded. SQLITE_THREADSAFE=0 устанавливает по умолчанию threading mode в Single-threaded.

SQLITE_THREADSAFE может быть определен во время выполнения, используя sqlite3_threadsafe().

Когда SQLite был собран с SQLITE_THREADSAFE=1 или SQLITE_THREADSAFE=2, тогда threading mode может быть изменен во времени выполнения, используя sqlite3_config() вместе с одним из этих терминов:

• SQLITE_CONFIG_SINGLETHREAD
• SQLITE_CONFIG_MULTITHREAD
• SQLITE_CONFIG_SERIALIZED

SQLITE_OPEN_NOMUTEX и SQLITE_OPEN_FULLMUTEX определяют, что sqlite3_open_v2() может также использоваться, чтобы приспособить threading mode отдельного соединения с базой данных во время выполнения.

Обратите внимание на то, что, когда SQLite собран с SQLITE_THREADSAFE=0, код, чтобы сделать SQLite ориентированным на многопотоковое исполнение, не собран вообще. Когда это происходит, невозможно изменить threading mode когда-либо.

См. документацию threading mode для получения дополнительной информации об аспектах использования SQLite в многопоточной окружающей среде.

SQLITE_TEMP_STORE=<0-3>

Этот выбор управляет, хранятся ли временные файлы на диске или в памяти. Значения для различных параметров настройки этого выбора времени компиляции следующие:

SQLITE_TEMP_STORE	Смысл
0	Всегда используйте временные файлы
1	Используйте файлы по умолчанию, но позвольте PRAGMA temp_store для изменения
2	Используйте память по умолчанию, но позвольте PRAGMA temp_store для изменения
3	Всегда используйте память

По умолчанию 1. Дополнительная информация может быть найдена в tempfiles.html.

SQLITE_TRACE_SIZE_LIMIT=N

Если этот макрос определяется к положительному целому числу N, то длина последовательностей и BLOB, которые расширены в параметры в выводе sqlite3_trace(), ограничена N байт.

SQLITE_TRUSTED_SCHEMA=<0 или 1>

Этот макрос определяет значение по умолчанию для SQLITE_DBCONFIG_TRUSTED_SCHEMA и PRAGMA trusted_schema. Если никакая альтернатива не определяется, доверяемая схема, устанавливает умолчания в ON (значение 1) для совместимости с прежними системами. Однако для лучшей безопасности, системы, которые осуществляют определенные применением функции SQL и/или виртуальные таблицы должны рассмотреть изменение умолчания в OFF.

SQLITE_USE_URI

Этот выбор заставляет логику процесса URI filename быть позволенной по умолчанию.

7. Варианты активировать обычно выключенные опции

SQLITE_ALLOW_URI_AUTHORITY

Имена файлов URI обычно бросают ошибку, если часть авторизации не пуста или "localhost". Однако, если SQLite собран с выбором времени компиляции SQLITE_ALLOW_URI_AUTHORITY, то URI преобразовывается в имя файла Uniform Naming Convention (UNC) и передается к основной операционной системе.

Некоторые будущие версии SQLite могут измениться, чтобы активировать эту опцию по умолчанию.

SQLITE_ALLOW_COVERING_INDEX_SCAN=<0 или 1>

Этот макрос определяет настройку по умолчанию параметра конфигурации SQLITE_CONFIG_COVERING_INDEX_SCAN. Это по умолчанию 1 (on), значит покрывающие индексы используются для полного сканирования таблицы, если это возможно, чтобы уменьшить I/O и улучшить работу. Однако использование закрывающего индекса для полного просмотра заставляет результаты появиться в различном порядке от наследия, которое могло заставить некоторые (неправильно закодированные) унаследованные приложения ломаться. Следовательно, выбор просмотра индекса может быть отключен во время компиляции, что минимизировать риск ошибок в унаследованных приложениях.

SQLITE_ENABLE_8_3_NAMES=<1 или 2>

Если этот макрос C-препроцессора определяется, то дополнительный код включен, который позволяет SQLite функционировать в файловой системе, которая понимает только имена файлов 8+3. Если значение этого макроса равняется 1, то поведение по умолчанию должно продолжить использовать длинные имена файлов и использовать имена файлов 8+3 только если соединение с базой данных открыто, используя URI filenames с параметром запроса "8_3_names=1". Если значение этого макроса равняется 2, то использование 8+3 имен файлов становится умолчанием, но может быть отключено при использовании параметра запроса 8_3_names=0.

SQLITE_ENABLE_API_ARMOR

Когда определено, этот макрос C-препроцессора активирует дополнительный код, который пытается обнаружить неправильное употребление API SQLite, такого как передача NULL обязательным параметрам или использование объектов после того, как они были разрушены. Когда этот выбор позволен, и незаконное использование API обнаружено, интерфейс будет, как правило, возвращать SQLITE_MISUSE.

SQLITE_ENABLE_API_ARMOR не гарантирует, что будут обнаружены все незаконные использования API. Даже когда SQLITE_ENABLE_API_ARMOR позволен, передача неправильного значения C API может вызвать катастрофу процесса из-за ошибки сегментации или других причин. Выбор времени компиляции SQLITE_ENABLE_API_ARMOR предназначается как помощь для прикладного тестирования и отладки. Приложения не должны зависеть от SQLITE_ENABLE_API_ARMOR для безопасности. SQLITE_ENABLE_API_ARMORE это второй оборонительный рубеж против прикладных ошибок, но это не должна быть единственной защитой. Если какой-либо интерфейс SQLite возвращает SQLITE_MISUSE, это указывает, что приложение использует SQLite вопреки правилам и что применение содержит ошибку. Возвращение SQLITE_MISUSE предоставляет применению возможность изящно ответить той ошибке, вместо того, чтобы просто разбить процесс, но ничего больше.

SQLITE_ENABLE_ATOMIC_WRITE

Если этот макрос C-препроцессора определяется и если метод xDeviceCharacteristics объекта sqlite3_io_methods для файла базы данных сообщает (через один из битов SQLITE_IOCAP_ATOMIC), что файловая система поддерживает атомную запись и если транзакция включает изменение только единственной страницы файла базы данных, то транзакция передается только с одним запросом на запись единственной страницы базы данных, и никакой журнал обратной перемотки не создан. В файловых системах, которые поддерживают атомную запись, эта оптимизация может привести к значительным улучшениям скорости для маленьких обновлений. Однако немного файловых систем поддерживают эту способность и пути выполнения кода, которые проверяют на эту способность, замедляют производительность записи на системах без атомной записи. Таким образом, эта опция отключена по умолчанию.

SQLITE_ENABLE_BATCH_ATOMIC_WRITE

Этот выбор времени компиляции позволяет SQLite воспользоваться преимуществом пакетной атомной записи в основной файловой системе. С версии 3.21.0 (2017-10-24) SQLite это поддерживается только на F2FS. Однако интерфейс осуществляется в общем, используя sqlite3_file_control() с SQLITE_FCNTL_BEGIN_ATOMIC_WRITE и SQLITE_FCNTL_COMMIT_ATOMIC_WRITE, таким образом, способность может быть добавлена к другим файловым системам в будущем. Когда этот выбор позволен, SQLite автоматически обнаруживает, что файловая система понимает пакетную атомную запись и избегает писать журнал обратной перемотки для управления транзакциями. Это может передать вдвое более быстрые транзакции, одновременно уменьшая износ устройств хранения данных SSD.

Будущие версии SQLite могли бы позволить эту возможность по умолчанию, тогда этот выбор времени компиляции станет лишним.

SQLITE_ENABLE_BYTECODE_VTAB

Этот выбор позволяет виртуальные таблицы tables_used и байт-кода.

SQLITE_ENABLE_COLUMN_METADATA

Когда этот макрос C-препроцессора определяется, SQLite включает некоторый дополнительный API, которые обеспечивают удобный доступ к метаданным о таблицах и запросах. API, которые позволены этим выбором:

• sqlite3_column_database_name()
• sqlite3_column_database_name16()
• sqlite3_column_table_name()
• sqlite3_column_table_name16()
• sqlite3_column_origin_name()
• sqlite3_column_origin_name16()

SQLITE_ENABLE_DBPAGE_VTAB

Этот выбор позволяет виртуальную таблицу SQLITE_DBPAGE.

SQLITE_ENABLE_DBSTAT_VTAB

Этот выбор позволяет виртуальную таблицу dbstat.

SQLITE_ENABLE_DESERIALIZE

раньше использовался, чтобы позволить the sqlite3_serialize() и sqlite3_deserialize(). Однако с SQLite 3.36.0 (2021-06-18) те интерфейсы позволены по умолчанию и новый выбор времени компиляции SQLITE_OMIT_DESERIALIZE добавляется, чтобы отключить их.

SQLITE_ENABLE_EXPLAIN_COMMENTS

Этот выбор добавляет дополнительную логику к SQLite, которая вставляет текст комментария в вывод EXPLAIN. Эти дополнительные комментарии используют дополнительную память, таким образом делая подготовленные запросы больше и очень немного медленнее, таким образом, они выключены по умолчанию и в большей части применения. Но некоторые запросы, такие как оболочка командной строки для SQLite, используют сырой вывод EXPLAIN и этот выбор времени компиляции доступен им. Выбор времени компиляции SQLITE_ENABLE_EXPLAIN_COMMENTS также позволен автоматически, если включен SQLITE_DEBUG.

SQLITE_ENABLE_FTS3

Когда этот выбор определяется в объединении, версии 3 и 4 полнотекстовой поисковой системы добавляются.

SQLITE_ENABLE_FTS3_PARENTHESIS

Этот выбор изменяет анализатор образца запроса в FTS3, таким образом, что это поддерживает операторы AND и NOT (в дополнение к обычному OR и NEAR) и также позволяет выражениям запроса содержать вложенную круглую скобку.

SQLITE_ENABLE_FTS3_TOKENIZER

Этот выбор позволяет версию с двумя аргументами fts3_tokenizer(). Второй аргумент fts3_tokenizer() должен быть указателем на функцию (закодированную как BLOB), которая реализовывает определенный токенизатор приложения. Если враждебные хакеры в состоянии управлять версией с двумя аргументами fts3_tokenizer() с произвольным вторым аргументом, они могли устроить катастрофу или взять под свой контроль процесс.

Из-за проблем безопасности fts3_tokenizer с двумя аргументами опция была отключена, начиная с Version 3.11.0 (2016-02-15), если этот выбор времени компиляции не используется. Version 3.12.0 (2016-03-29) добавила sqlite3_db_config(db, SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER,1,0), который активирует версию с двумя аргументами fts3_tokenizer() для определенного соединения с базой данных во время выполнения.

SQLITE_ENABLE_FTS4

Когда этот выбор определяется в объединении, версии 3 и 4 полнотекстовой поисковой системы добавляются.

SQLITE_ENABLE_FTS5

Когда этот выбор определяется в объединении, версия 5 полнотекстовой поисковой системы (fts5) добавлена.

SQLITE_ENABLE_GEOPOLY

Когда этот выбор определяется в объединении, расширение Geopoly добавлено в сборку.

SQLITE_ENABLE_ICU

Этот выбор заставляет International Components for Unicode или расширение "ICU" SQLite быть добавленными.

SQLITE_ENABLE_IOTRACE

Когда ядро SQLite и Command Line Interface (CLI) собраны с этим выбором, тогда CLI обеспечивает дополнительную команду ".iotrace", которая предоставляет журнал низкого уровня деятельности I/O. Этот выбор экспериментален и может быть прекращен в будущем выпуске.

SQLITE_ENABLE_MATH_FUNCTIONS

Этот макрос позволяет встроенные математические функции SQL. Этот выбор автоматически добавляется к Make-файлу, созданному скриптом на платформах Unix, если не используется --disable-math. Этот выбор также включен в Windows при сборке через "Makefile.msc" для nmake.

SQLITE_ENABLE_JSON1

Эта опция ничего не делает. До SQLite version 3.38.0 (2022-02-22) SQLite было необходимо собрать с этим выбором, чтобы включить функции JSON SQL. Но с SQLite version 3.38.0 эти функции включены по умолчанию. Используйте -DSQLITE_OMIT_JSON для выключения.

SQLITE_ENABLE_LOCKING_STYLE

Этот выбор позволяет дополнительную логику в слое интерфейса OS для Mac OS X. Дополнительная логика пытается определить тип основной файловой системы и выбрать альтернативную стратегию блокировки, которая работает правильно. Пять стратегий доступны:

• POSIX. Это стиль блокировки по умолчанию и стиль, используемый другими (не Mac OS X) Unix. Блокировки получены и выпущены через fcntl().

• AFP. Этот стиль блокировки используется для сетевых файловых систем, которые используют AFP (Apple Filing Protocol). Блокировки получены, вызвав библиотечную функцию _AFPFSSetLock().

• Flock. Это используется для файловых систем, которые не поддерживают блокировки POSIX. Блокировки получены и выпущены через flock().

• Dot-file. Этот стиль используется, когда flock или POSIX не поддерживаются файловой системой. Блокировки базы данных получены, создав запись в файловой системе в известном местоположении относительно файла базы данных ("dot-file"), и сняты, удалив тот файл.

• No locking. Если ни одно из вышеупомянутого не может быть поддержано, этот стиль используется. Никакой механизм блокировки базы данных не используется. Когда эта система используется, для единой базы данных небезопасно предоставлять достут сразу нескольким клиентам.

Кроме того, пять дополнительных внедрений VFS обеспечиваются, а также умолчание. Определяя одно из дополнительных внедрений VFS, вызывая sqlite3_open_v2(), приложение может обойти логику обнаружения файловой системы и явно выбрать один из вышеупомянутых стилей. Пять дополнительных внедрений VFS это "unix-posix", "unix-afp", "unix-flock", "unix-dotfile" и "unix-none".

SQLITE_ENABLE_MEMORY_MANAGEMENT

Этот выбор добавляет дополнительную логику к SQLite, который позволяет ему освобождать неиспользованную память по запросу. Этот выбор должен быть позволен для sqlite3_release_memory(). Если этот выбор времени компиляции не используется, sqlite3_release_memory() ничего не делает.

SQLITE_ENABLE_MEMSYS3

Этот выбор включает код в SQLite, который осуществляет альтернативного распределителя памяти. Этот альтернативный распределитель памяти используется только когда SQLITE_CONFIG_HEAP используется в sqlite3_config(), чтобы поставлять большой кусок памяти, от которой взяты все выделения памяти. Распределитель памяти MEMSYS3 использует гибридный алгоритм назначения, скопированный после dlmalloc(). Только один из SQLITE_ENABLE_MEMSYS3 и SQLITE_ENABLE_MEMSYS5 может быть позволен сразу.

SQLITE_ENABLE_MEMSYS5

Этот выбор включает код в SQLite, который осуществляет альтернативного распределителя памяти. Этот альтернативный распределитель памяти используется только когда SQLITE_CONFIG_HEAP используется в sqlite3_config(), чтобы поставлять большой кусок памяти, от которой взяты все выделения памяти. Модуль MEMSYS5 округляет все отчисления до следующей степени 2 и использует первую подгонку, алгоритм распределителя, который обеспечивает сильные гарантии от фрагментации и сбоев с определенными операционными ограничениями.

SQLITE_ENABLE_NORMALIZE

Этот выбор включает sqlite3_normalized_sql() API.

SQLITE_ENABLE_NULL_TRIM

Этот выбор позволяет оптимизацию, которая опускает колонки NULL в концах строк для экономии места на диске.

Базы данных, произведенные с этим выбором, нечитаемы версией SQLite version 3.1.6 (2005-03-17) и ранее. Кроме того, базы данных, произведенные с этим выбором, подвержены сбою e6e962d6b0f06f46 в sqlite3_blob_reopen(). По этим причинам эта оптимизация отключена по умолчанию. Однако, эта оптимизация может быть позволена по умолчанию в будущем выпуске SQLite.

SQLITE_ENABLE_OFFSET_SQL_FUNC

Этот выбор позволяет поддержку SQL-функции sqlite_offset(X).

sqlite_offset(X) требует нового интерфейса в механизме хранения B-дерева, нового кода операции в виртуальной машине, которая управляет SQL-операторами и новым условным предложением в критическом пути генератора кода. Чтобы избежать издержек в запросах, для которых не нужна sqlite_offset(X), функция была отключена по умолчанию.

SQLITE_ENABLE_PREUPDATE_HOOK

Этот выбор позволяет несколько новых API, которые обеспечивают отзывы до любого изменения таблицы rowid. Отзывы могут использоваться, чтобы сделать запись статуса строки прежде, чем изменение произойдет.

Перехват перед обновлением подобен перехвату update за исключением того, что отзыв призван перед изменением, не впоследствии, и интерфейсы перехвата перед обновлением опущены, если этот выбор времени компиляции не используется.

Интерфейсы перехвата перед обновлением были первоначально добавлены, чтобы поддержать расширение session.

SQLITE_ENABLE_QPSG

Этот выбор заставляет включить query planner stability guarantee (QPSG) по умолчанию. Обычно QPSG выключен и должен быть активирован во время выполнения, используя выбор SQLITE_DBCONFIG_ENABLE_QPSG в интерфейсе sqlite3_db_config() interface.

SQLITE_ENABLE_RBU

Включить расширение RBU.

SQLITE_ENABLE_RTREE

Этот выбор заставляет SQLite включать поддержку расширения R*Tree index.

SQLITE_ENABLE_SESSION

Этот выбор заставляет SQLite включать поддержку расширения session.

SQLITE_ENABLE_SNAPSHOT

Этот выбор заставляет SQLite включать поддержку объекта sqlite3_snapshot и связанных интерфейсов:

• sqlite3_snapshot_get() (constructor)
• sqlite3_snapshot_free() (destructor)
• sqlite3_snapshot_open()
• sqlite3_snapshot_cmp()
• sqlite3_snapshot_recover()

SQLITE_ENABLE_SORTER_REFERENCES

Этот выбор активирует оптимизацию, которая уменьшает память, требуемую сортировщиком за счет выполнения дополнительных поисков B-дерева после того, как сортировка закончена.

Процедура сортировки по умолчанию должна собрать всю информацию, которая будет в конечном счете произведена в записи и передаст полный отчет сортировщику. Но в некоторых случаях, например если некоторые колонки состоят из больших значений BLOB, размер каждого отчета может быть большим, что означает, что сортировщик должен или использовать больше памяти и/или написать больше содержания во временное хранилище.

Когда включен SQLITE_ENABLE_SORTER_REFERENCES, отчеты, переданные сортировщику, часто содержат только значение ROWID. Такие отчеты значительно уменьшенные. Это означает, что сортировщик имеет намного меньше "полезного груза" и может работать быстрее. После того, как сортировка произошла, ROWID используется, чтобы искать значения столбцов вывода в оригинальной таблице. Это требует другого поиска в таблице и могло потенциально привести к замедлению. Или, это могла бы быть победа производительности, в зависимости от того, насколько большое значение.

Даже когда выбор времени компиляции SQLITE_ENABLE_SORTER_REFERENCES = on, ссылки сортировщика все еще отключены по умолчанию. Чтобы использовать ссылки сортировщика, приложение должно установить справочный порог размера сортировщика, используя sqlite3_config( SQLITE_CONFIG_SORTERREF_SIZE) при запуске.

Поскольку разработчики SQLite не знают, поможет ли выбор SQLITE_ENABLE_SORTER_REFERENCES или повредит, он отключен по умолчанию в это время (2018-05-04). Это могло бы быть позволено по умолчанию в некотором будущем выпуске, в зависимости от того, что становится известно о его воздействии.

SQLITE_ENABLE_STMT_SCANSTATUS

Этот выбор позволяет sqlite3_stmt_scanstatus() и sqlite3_stmt_scanstatus_v2(). Эти интерфейсы обычно не собираются потому, что они вызывают потерю производительности, даже на запросах, которые не используют функцию.

SQLITE_ENABLE_STMTVTAB

Этот выбор времени компиляции позволяет логику виртуальной таблицы SQLITE_STMT.

SQLITE_RTREE_INT_ONLY

Этот выбор времени компиляции удержан от использования и не проверен.

SQLITE_ENABLE_SQLLOG

Этот выбор позволяет дополнительный код (специальный выбор SQLITE_CONFIG_SQLLOG для sqlite3_config() ), который может использоваться, чтобы создать регистрации всей обработки SQLite, выполненной приложением. Эти регистрации могут быть полезными в выполнении офлайнового анализа поведения и специально для исполнительного анализа. Для SQLITE_ENABLE_SQLLOG, чтобы быть полезным, требуется некоторый дополнительный код. Файл исходного кода "test_sqllog.c" в исходном дереве SQLite это рабочий пример необходимого дополнительного кода. На Unix и windows разработчик может добавить текст "test_sqllog.c" в конец файла объединения "sqlite3.c", повторно собрать приложение, используя -DSQLITE_ENABLE_SQLLOG, затем управлять регистрацией, используя переменные окружения. Посмотрите заголовочный комментарий в "test_sqllog.c" для подробностей.

SQLITE_ENABLE_STAT2

Этот выбор, используемый, чтобы заставить команду ANALYZE собирать данные о гистограмме индекса в таблице sqlite_stat2. Но та функциональность была заменена SQLITE_ENABLE_STAT3 с SQLite version 3.7.9 (2011-11-01). SQLITE_ENABLE_STAT2 теперь ничего не делает.

SQLITE_ENABLE_STAT3

Этот выбор, используемый, чтобы заставить команду ANALYZE собирать данные о гистограмме индекса в таблице sqlite_stat2. Но та функциональность была заменена SQLITE_ENABLE_STAT4 с SQLite version 3.8.1 (2013-10-17). SQLITE_ENABLE_STAT3 продолжал поддерживаться до version 3.29.0 (2019-07-10), но теперь ничего не делает.

SQLITE_ENABLE_STAT4

Этот выбор добавляет дополнительную логику к команде ANALYZE и планировщику запроса, которая может помочь SQLite выбрать лучший план запросов в определенных ситуациях. Команда ANALYZE увеличивается, чтобы собрать данные о гистограмме из всех колонок каждого индекса и хранить те данные в таблице sqlite_stat4. Планировщик запроса будет тогда использовать данные о гистограмме, чтобы помочь сделать лучший выбор индекса. Оборотная сторона этого выбора времени компиляции в том, что он нарушает query planner stability guarantee, делающую труднее гарантирование последовательной работы в выпускаемых серийно запросах.

SQLITE_ENABLE_STAT4 это расширение SQLITE_ENABLE_STAT3. STAT3 только сделал запись данных о гистограмме для крайнего левого столбца каждого индекса, тогда как улучшение STAT4 делает запись данных о гистограмме из всех колонок каждого индекса. Выбор времени компиляции SQLITE_ENABLE_STAT3 ничего не делает.

SQLITE_ENABLE_TREE_EXPLAIN

Этот выбор времени компиляции больше не используется.

SQLITE_ENABLE_UPDATE_DELETE_LIMIT

Этот выбор позволяет дополнительный ORDER BY и пункт LIMIT в UPDATE и DELETE.

Если этот выбор определяется, то он должен также быть определен, используя Lemon parser generator, чтобы произвести файл parse.c. Из-за этого этот выбор может использоваться только когда библиотека строится из исходных текстов, а не из объединения или из коллекции предварительно упакованных файлов C для не-Unix систем.

SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION

Когда выбор времени компиляции SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION будет активирован, SQLite подавит ошибки "unknown function" при выполнении EXPLAIN или EXPLAIN QUERY PLAN. Вместо того, чтобы бросить ошибку, SQLite вставит замену пустой функцией с именем "unknown()". Подстановка "unknown()" вместо непризнанных функций происходит только в EXPLAIN и EXPLAIN QUERY PLAN, не на обычных запросах.

Когда используется в оболочке командной строки, SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION позволяет код на SQL, который содержит определенные применением функции, которые будут приклеиваться в обоочку для анализа и отладки, не имея необходимости создавать и загружать расширение, которое осуществляет определенные приложением функции.

SQLITE_ENABLE_UNLOCK_NOTIFY

Этот выбор позволяет sqlite3_unlock_notify() и его связанную функциональность. Посмотрите документацю здесь.

SQLITE_INTROSPECTION_PRAGMAS

Этот выбор устаревший. Это раньше позволяло некоторые дополнительные команды PRAGMA, например, PRAGMA function_list, PRAGMA module_list и PRAGMA pragma_list, но они теперь все позволены по умолчанию. См. SQLITE_OMIT_INTROSPECTION_PRAGMAS.

SQLITE_SOUNDEX

Этот выбор позволяет SQL-функцию soundex().

SQLITE_USE_ALLOCA

Если этот выбор будет позволен, то распределитель памяти alloca() будет использоваться в нескольких ситуациях, где это подходит. Это приводит к немного меньшему и более быстрому коду. SQLITE_USE_ALLOCA работает, конечно, на системах, которые поддерживают alloca().

SQLITE_USE_FCNTL_TRACE

Этот выбор заставляет SQLite выпускать дополнительные средства управления файлом SQLITE_FCNTL_TRACE, чтобы предоставить дополнительную информацию VFS. Расширение "vfslog.c" использует это, чтобы предоставить увеличенные журналы деятельности VFS.

SQLITE_USE_SEH

Этот выбор включает Structured Exception Handling (SEH) в Windows. SEH это определенная для Windows техника для ловли исключений, поднятых, получая доступ к файлу с отображенной памятью. SEH используется, чтобы перехватить ошибки, которые могли бы произойти, получая доступ к файлу shm, с отображенной памятью, которые являются частью обработки режима WAL. Если операционная система подняла ошибки, в то время как SQLite пытается получить доступ к файлу shm, этот выбор заставляет те ошибки быть пойманными и работать с SQLite, вместо того, чтобы прервать процесс.

Этот выбор работает только, собирая в Windows с MSVC.

SQLITE_HAVE_ZLIB

Этот выбор заставляет некоторые расширения связываться с библиотекой сжатия zlib.

Этот выбор не имеет никакого эффекта на ядро SQLite. Это используется только расширениями. Этот выбор необходим для функций сжатия и декомпрессии, которые являются частью поддержки архивов SQL в оболочке командной строки.

Собирая с этим выбором, обычно будет необходимо добавить выбор компоновщика, чтобы включить библиотеку zlib. Обычно это "-lz".

Собирая с MSVC на системах Windows, можно поместить исходный код zlib в подкаталог compat/zlib исходного дерева и затем добавить выбор USE_ZLIB=1 к команде nmake, чтобы заставить Makefile.msc автоматически использовать соответствующее внедрение zlib библиотеки.

YYTRACKMAXSTACKDEPTH

Этот выбор заставляет глубину стека парсера LALR(1) отслеживаться и сообщает через sqlite3_status( SQLITE_STATUS_PARSER_STACK,...). У SQLite LALR(1) есть фиксированная глубина стека (определенная во время компиляции с использованием вариантов YYSTACKDEPTH). Этот выбор может использоваться, чтобы помочь определить, рядом ли приложение с превышением максимальной глубины стека LALR(1).

8. Варианты отключить обычно включенные опции

SQLITE_DISABLE_LFS

Если этот макрос C-препроцессора определяется, поддержка больших файлов отключена.

SQLITE_DISABLE_DIRSYNC

Если этот макрос C-препроцессора определяется, синхронизации каталогов отключены. SQLite, как правило, пытается синхронизировать родительский каталог, когда файл удален, чтобы гарантировать, что записи каталога немедленно обновляются на диске.

SQLITE_DISABLE_FTS3_UNICODE

Если этот макрос C-препроцессора определяется, токенизатор unicode61 в FTS3 не собирается и недоступен.

SQLITE_DISABLE_FTS4_DEFERRED

Если этот макрос C-препроцессора определен, он отключает "отсроченную символическую" оптимизацию в FTS4. "Отсроченная символическая" оптимизация избегает загружать крупные списки регистрации для условий, которые находятся в большинстве документов коллекции, и вместо этого просто просматривает для тех символов источник документа. FTS4 должен получить точно тот же самый ответ с и без этой оптимизации.

SQLITE_DISABLE_INTRINSIC

Этот выбор отключает использование определенных для компилятора встроенных функций, например, __builtin_bswap32() и __builtin_add_overflow() в GCC и Clang или _byteswap_ulong() и _ReadWriteBarrier() в MSVC.

9. Варианты пропустить особенности

Следующие варианты могут использоваться, чтобы уменьшить размер собранной библиотеки, опуская неиспользованные особенности. Это, вероятно, полезно только во встроенных системах, где место особенно дорого, поскольку даже со всеми особенностями библиотека SQLite относительно маленькая. Не забывайте говорить вашему компилятору оптимизировать для двоичного размера (опция -Os в GCC). Сообщение вашему компилятору оптимизировать размер обычно оказывает намного большее влияние на габариты библиотеки, чем использование любого из этих вариантов времени компиляции. Необходимо также проверить, что выключены опции отладки.

Макрос в этой секции не требует значений. Следующие переключатели все имеют тот же самый эффект:
-DSQLITE_OMIT_ALTERTABLE
-DSQLITE_OMIT_ALTERTABLE=1
-DSQLITE_OMIT_ALTERTABLE=0

Если какой-либо из этих вариантов определяется, то тот же самый набор вариантов SQLITE_OMIT_* должен также быть определен, используя Lemon parser generator, чтобы произвести файл parse.c и затем применить инструмент 'mkkeywordhash', который производит файл keywordhash.h. Из-за этого эти варианты могут использоваться только, когда библиотека строится из канонического источника, не из объединения. Некоторые варианты SQLITE_OMIT_* могли бы работать, когда используются с объединением. Но это не гарантируется. В целом всегда собирайте из канонических источников, чтобы использовать в своих интересах варианты SQLITE_OMIT_*.

Важно: варианты SQLITE_OMIT_* могут не работать с объединением. Варианты времени компиляции SQLITE_OMIT_* обычно работают правильно только когда SQLite строится из канонических исходных файлов.

Могут быть произведены специальные версии объединения SQLite, которые действительно работают с предопределенным набором вариантов SQLITE_OMIT_*. Чтобы сделать так, сделайте копию шаблона make-файла Makefile.linux-gcc в каноническом дистрибутиве исходного кода. Поменяйте имя своей копии на просто "Makefile". Теперь отредактируйте "Makefile", чтобы настроить соответствующие варианты времени компиляции. Затем:

make clean; make sqlite3.c

Итоговый кодовый файл объединения "sqlite3.c" (и его связанный заголовочный файл "sqlite3.h") может тогда быть перемещен в платформу не-Unix для заключительной компиляции, используя родной компилятор.

Варианты SQLITE_OMIT_* не поддерживаются. Этим мы подразумеваем, что выбор SQLITE_OMIT_*, который опускает код в текущем релизе, мог бы стать нерабочим в следующем выпуске. Или наоборот: SQLITE_OMIT_*, который является нерабочим в текущем выпуске, мог бы заставить код быть исключенным в следующем выпуске. Кроме того, не все варианты SQLITE_OMIT_* проверены. Некоторые варианты SQLITE_OMIT_* могли бы заставить SQLite работать со сбоями и/или предоставлять неправильные ответы.

Важно: варианты времени компиляции SQLITE_OMIT_* главным образом не поддерживаются.

Следующее это доступные варианты OMIT:

SQLITE_OMIT_ALTERTABLE

Когда этот выбор определяется, команда ALTER TABLE не включена в библиотеку. Выполнение запроса ALTER TABLE вызывает ошибку анализа.

SQLITE_OMIT_ANALYZE

Когда этот выбор определяется, команда ANALYZE не собирается.

SQLITE_OMIT_ATTACH

Когда этот выбор определяется, команды ATTACH и DETACH не собираются.

SQLITE_OMIT_AUTHORIZATION

Определение этого выбора опускает особенность отзыва авторизации из библиотеки. sqlite3_set_authorizer() API не присутствует в библиотеке.

SQLITE_OMIT_AUTOINCREMENT

Этот выбор, опускает особенность AUTOINCREMENT. Когда этот макрос определяется, колонки, объявленные как "INTEGER PRIMARY KEY AUTOINCREMENT", ведут себя таким же образом как колонки, объявленные как "INTEGER PRIMARY KEY" при вставке NULL. Системная таблица sqlite_sequence не создают и игнорируют, если она уже существует.

SQLITE_OMIT_AUTOINIT

Для обратной совместимости с более старыми версиями SQLite, которые не имеют sqlite3_initialize(), sqlite3_initialize() вызывается автоматически после входа в определенные ключевые интерфейсы, такие как sqlite3_open(), sqlite3_vfs_register() и sqlite3_mprintf(). Вызов sqlite3_initialize() автоматически таким образом может быть опущен, строя SQLite с макросом C-препроцессора SQLITE_OMIT_AUTOINIT. Когда построено, используя SQLITE_OMIT_AUTOINIT, SQLite автоматически не инициализирует себя, и приложение должно вызвать sqlite3_initialize() непосредственно до использования библиотеки SQLite.

SQLITE_OMIT_AUTOMATIC_INDEX

Этот выбор используется, чтобы пропустить автоматическое индексирование. См. также: SQLITE_DEFAULT_AUTOMATIC_INDEX.

SQLITE_OMIT_AUTORESET

По умолчанию sqlite3_step() автоматически вызовет sqlite3_reset(), чтобы перезагрузить подготовленный запрос при необходимости. Это меняет поведение так, чтобы sqlite3_step() вернул SQLITE_MISUSE, если это вызывает снова после возвращения чего-нибудь кроме SQLITE_ROW, SQLITE_BUSY или SQLITE_LOCKED, если не было прошедшего вызова sqlite3_reset().

В SQLite version 3.6.23.1 (2010-03-26) и ранее sqlite3_step() используется, чтобы всегда возвратить SQLITE_MISUSE, если это было вызвано снова после возвращения чего-нибудь кроме SQLITE_ROW без прошедшего вызова sqlite3_reset(). Это вызвало проблемы на некоторых плохо написанных приложениях смартфона, которые правильно не обращались с ошибками SQLITE_LOCKED и SQLITE_BUSY. Вместо того, чтобы править много дефектных приложений смартфона, поведение SQLite было изменено в 3.6.23.2, чтобы автоматически перезагрузить подготовленный запрос. Но это изменило вызванные проблемы в других неправильно реализованных приложениях, которые на самом деле искали возвращение SQLITE_MISUSE, чтобы закончить их циклы запроса. Каждый раз, когда приложение получает код ошибки SQLITE_MISUSE от SQLite, который означает, что приложение неправильно использует интерфейс SQLite и таким образом неправильно реализовано. Интерфейс SQLITE_OMIT_AUTORESET был добавлен в SQLite version 3.7.5 (2011-02-01), чтобы все (сломанные) запросы смогли работать снова, не имея необходимости на самом деле их исправлять.

SQLITE_OMIT_AUTOVACUUM

Если этот выбор определяется, библиотека не может создать или написать базы данных, которые поддерживают auto_vacuum. Выполнение PRAGMA auto_vacuum не является ошибкой (так как неизвестные PRAGMA тихо проигнорированы), но не возвращает значение или изменяет автовакуумный флаг в файле базы данных. Если база данных, которая поддерживает автовакуум, открыта библиотекой, собранной с этим выбором, это автоматически открыто в режиме только для чтения.

SQLITE_OMIT_BETWEEN_OPTIMIZATION

Этот выбор отключает использование индексов с условиями оператора Where, которые используют оператор BETWEEN.

SQLITE_OMIT_BLOB_LITERAL

Когда этот выбор определяется, невозможно определить blob в SQL-операторе, используя синтаксис X'ABCD'.

SQLITE_OMIT_BTREECOUNT

Этот выбор больше не используется ни для чего.

SQLITE_OMIT_BUILTIN_TEST

Этот выбор времени компиляции был переименован в SQLITE_UNTESTABLE.

SQLITE_OMIT_CASE_SENSITIVE_LIKE_PRAGMA

Этот выбор времени компиляции отключает PRAGMA case_sensitive_like.

SQLITE_OMIT_CAST

Этот выбор заставляет SQLite опускать поддержку оператора CAST.

SQLITE_OMIT_CHECK

Этот выбор заставляет SQLite опускать поддержку ограничений CHECK. Анализатор все еще примет ограничения CHECK в SQL-операторах, они просто не будут проведены в жизнь.

SQLITE_OMIT_COMPILEOPTION_DIAGS

Этот выбор используется, чтобы опустить диагностику выбора времени компиляции, доступную в SQLite, включая функции C/C++ sqlite3_compileoption_used() и sqlite3_compileoption_get(), функции SQL sqlite_compileoption_used() и sqlite_compileoption_get(), а также compile_options pragma.

SQLITE_OMIT_COMPLETE

Этот выбор заставляет не собирать sqlite3_complete() и sqlite3_complete16().

SQLITE_OMIT_COMPOUND_SELECT

Этот выбор используется, чтобы пропустить составную функциональность SELECT. SELECT, которые используют UNION, UNION ALL, INTERSECT или EXCEPT compound SELECT вызовут ошибку анализа.

INSERT с многократными значениями в VALUES осуществляется внутренне как составной SELECT. Следовательно, этот выбор также отключает способность вставить больше, чем единственную строку, используя INSERT INTO ... VALUES ....

SQLITE_OMIT_CTE

Этот выбор заставляет не собирать поддержку общих выражений таблицы.

SQLITE_OMIT_DATETIME_FUNCS

Если этот выбор определяется, встроенные функции манипуляции даты и времени SQLITE пропущены. Определенно, функции julianday(), date(), time(), datetime() и strftime() недоступны. Значения столбцов по умолчанию CURRENT_TIME, CURRENT_DATE и CURRENT_TIMESTAMP все еще доступны.

SQLITE_OMIT_DECLTYPE

Этот выбор заставляет SQLite пропускать поддержку sqlite3_column_decltype() и sqlite3_column_decltype16().

SQLITE_OMIT_DEPRECATED

Этот выбор заставляет SQLite опускать поддержку интерфейсов, отмеченных, как устаревшие. Это включает sqlite3_aggregate_count(), sqlite3_expired(), sqlite3_transfer_bindings(), sqlite3_global_recover(), sqlite3_thread_cleanup() и sqlite3_memory_alarm(), PRAGMA count_changes, PRAGMA data_store_directory, PRAGMA default_cache_size, PRAGMA empty_result_callbacks, PRAGMA full_column_names, PRAGMA short_column_names и PRAGMA temp_store_directory.

SQLITE_OMIT_DESERIALIZE

Этот выбор заставляет не собирать sqlite3_serialize() и sqlite3_deserialize().

SQLITE_OMIT_DISKIO

Этот выбор пропускает всю поддержку записи на диск и вынуждает базы данных существовать только в памяти. Этот выбор не поддерживается и вероятно не работает с более новыми версиями SQLite.

SQLITE_OMIT_EXPLAIN

Определение этого выбора заставляет не собирать команду EXPLAIN. Попытка выполнить запрос EXPLAIN вызовет ошибку анализа.

SQLITE_OMIT_FLAG_PRAGMAS

Этот выбор опускает прподдержку подмножества команд PRAGMA, которые запрашивают и устанавливают свойства boolean.

SQLITE_OMIT_FLOATING_POINT

Этот выбор используется, чтобы опустить поддержку числа с плавающей запятой со стороны библиотеки SQLite. Когда определено, определение числа с плавающей точкой как литерала (например, "1.01") приводит к ошибке анализа.

В будущем этот выбор может также отключить другую функциональность с плавающей точкой, например sqlite3_result_double(), sqlite3_bind_double(), sqlite3_value_double() и sqlite3_column_double() API.

SQLITE_OMIT_FOREIGN_KEY

Если этот выбор определяется, то foreign key constraint не признан.

SQLITE_OMIT_GENERATED_COLUMNS

Если этот выбор определяется, то generated column не признан.

SQLITE_OMIT_GET_TABLE

Этот выбор заставляет не собирать поддержку sqlite3_get_table() и sqlite3_free_table().

SQLITE_OMIT_HEX_INTEGER

Этот выбор пропускает поддержку hexadecimal integer literals.

SQLITE_OMIT_INCRBLOB

Этот выбор пропускает поддержку incremental BLOB I/O.

SQLITE_OMIT_INTEGRITY_CHECK

Этот выбор пропускает поддержку integrity_check pragma.

SQLITE_OMIT_INTROSPECTION_PRAGMAS

Этот выбор пропускает поддержку PRAGMA function_list, PRAGMA module_list и PRAGMA pragma_list.

SQLITE_OMIT_JSON

Этот выбор пропускает поддержку SQL-функций JSON.

SQLITE_OMIT_LIKE_OPTIMIZATION

Этот выбор отключает способность SQLite использовать индексы, чтобы помочь решить LIKE и GLOB в WHERE.

SQLITE_OMIT_LOAD_EXTENSION

Этот выбор пропускает весь механизм загрузки расширения SQLite, включая sqlite3_enable_load_extension() и sqlite3_load_extension().

SQLITE_OMIT_LOCALTIME

Этот выбор пропускает модификатор "localtime" функций даты и времени. Этот выбор иногда полезен, пытаясь собрать функции даты и времени на платформе, которая не поддерживает понятие местного времени.

SQLITE_OMIT_LOOKASIDE

Этот выбор пропускает lookaside memory allocator.

SQLITE_OMIT_MEMORYDB

Когда это определяется, библиотека не обрабатывает специальное имя базы данных ":memory:" (обычно используемое, чтобы создать базу данных в памяти). Если ":memory:" передать sqlite3_open(), sqlite3_open16() или sqlite3_open_v2(), файл с этим именем будет открыт или создан.

SQLITE_OMIT_OR_OPTIMIZATION

Этот выбор отключает способность SQLite использовать индекс вместе с условиями оператора Where, связанного операцией OR.

SQLITE_OMIT_PAGER_PRAGMAS

Определение этого выбора опускает pragma, связанный с подсистемой страниц.

SQLITE_OMIT_PRAGMA

Этот выбор используется, чтобы пропустить команду PRAGMA. Обратите внимание на то, что полезно определить макрос, которые опускают определенные pragma в дополнение к этому, поскольку они могут также удалить код поддержки в других подсистемах. Этот макрос удаляет только команду PRAGMA.

SQLITE_OMIT_PROGRESS_CALLBACK

Этот выбор может быть определен, чтобы пропустить способность освободить отзывы "progress" во время продолжительных SQL-операторов. sqlite3_progress_handler() API не присутствует в библиотеке.

SQLITE_OMIT_QUICKBALANCE

Этот выбор пропускает альтернативный более быстрый режим балансирования B-дерева. Использование этого выбора делает SQLite немного меньше за счет того, чтобы заставлять его работать немного медленнее.

SQLITE_OMIT_REINDEX

Когда этот выбор определяется, команда REINDEX не включена в библиотеку. Выполнение REINDEX вызывает ошибку анализа.

SQLITE_OMIT_SCHEMA_PRAGMAS

Определение этого выбора опускает pragma для запроса схемы базы данных.

SQLITE_OMIT_SCHEMA_VERSION_PRAGMAS

Определение этого выбора пропускает pragma для того, чтобы запросить и изменить версию схемы базы данных и пользовательскую версию. Определенно пропускаются PRAGMA schema_version и user_version.

SQLITE_OMIT_SHARED_CACHE

Этот выбор строит SQLite без поддержки shared cache mode. sqlite3_enable_shared_cache() опущен наряду с изрядным количеством логики в подсистеме B-дерева, связанной с общим управлением кэшем.

Этот выбор времени компиляции рекомендуют большинство приложений, поскольку он приводит к улучшенной работе и уменьшенному размеру библиотеки.

SQLITE_OMIT_SUBQUERY

Если определено, поддержка подвыборок и оператора IN() опущена.

SQLITE_OMIT_TCL_VARIABLE

Если этот макрос определяется, то специальный синтаксис "$", используемый, чтобы автоматически связать переменные SQL с переменными TCL, опущен.

SQLITE_OMIT_TEMPDB

Этот выбор опускает поддержку таблиц TEMP или TEMPORARY.

SQLITE_OMIT_TRACE

Этот выбор опускает поддержку sqlite3_profile() и sqlite3_trace() и их связанной логики.

SQLITE_OMIT_TRIGGER

Определение этого выбора опускает поддержку объектов TRIGGER. Ни один CREATE TRIGGER или DROP TRIGGER недоступны в этом случае, и попытка их выполнить не приведет к ошибке анализа. Этот выбор также отключает осуществление ограничений внешнего ключа, так как код, который осуществляет триггеры и опущен этим выбором, также используется, чтобы осуществить ограничения внешнего ключа.

SQLITE_OMIT_TRUNCATE_OPTIMIZATION

По умолчанию если DELETE не имеет никакого оператора Where и воздействует на таблицу без триггера, оптимизация происходит, которая заставляет DELETE происходить, удаляя и воссоздавая таблицу. Это обычно намного быстрее, чем удаление контента построчно. Это "truncate optimization".

SQLITE_OMIT_UTF16

Этот макрос используется, чтобы опустить поддержку текстового кодирования UTF16. Когда это определяется, все API-функции, которые возвращают или признают закодированный текст UTF16, недоступны. Эти функции могут быть определены тем, что они заканчиваются на '16', например, sqlite3_prepare16(), sqlite3_column_text16() и sqlite3_bind_text16().

SQLITE_OMIT_VACUUM

Когда этот выбор определяется, команда VACUUM не включена в библиотеку. Выполнение запроса VACUUM вызывает ошибку анализа.

SQLITE_OMIT_VIEW

Определение этого выбора опускает поддержку объектов VIEW. Ни CREATE VIEW, ни DROP VIEW недоступны в этом случае, попытка выполнить их приведет к ошибке анализа.

ВНИМАНИЕ: Если этот макрос будет определен, не будет возможно открыть базу данных, для которой схема содержит объекты VIEW.

SQLITE_OMIT_VIRTUALTABLE

Этот выбор опускает поддержку виртуальных таблиц в SQLite.

SQLITE_OMIT_WAL

Этот выбор опускает "журнал с упреждающей записью" (он же "WAL").

SQLITE_OMIT_WINDOWFUNC

Этот выбор опускает функции window.

SQLITE_OMIT_WSD

Этот выбор строит версию библиотеки SQLite, которая не содержит Writable Static Data (WSD). WSD это глобальные переменные и/или статические переменные. Некоторые платформы не поддерживают WSD, и этот выбор необходим для SQLite, чтобы работать на них.

В отличие от других вариантов OMIT, которые делают библиотеку SQLite меньше, этот выбор на самом деле увеличивает размер SQLite и заставляет ее работать немного медленнее. Используйте этот выбор, если SQLite строится для цели, которая не поддерживает WSD.

SQLITE_OMIT_XFER_OPT

Этот выбор опускает поддержку оптимизации, которая помогает запросам вида "INSERT INTO ... SELECT ..." работать быстрее.

SQLITE_UNTESTABLE

Стандартный SQLite включает небольшое количество логики, связанной с sqlite3_test_control(), чтобы осуществить части ядра SQLite, которые в других отношениях трудно утвердить. Этот выбор времени компиляции опускает ту дополнительную логику тестирования. Этот выбор времени компиляции называли "SQLITE_OMIT_BUILTIN_TEST" до SQLite version 3.16.0 (2017-01-02). Название было изменено, чтобы лучше описать последствия использования.

Урегулирование этого выбора времени компиляции препятствует тому, чтобы SQLite был полностью тестируемым. Тестовое покрытие понижается от 100% приблизительно до 95%.

Разработчики SQLite следуют за принципом NASA "fly what you test and test what you fly". Этот принцип нарушен, если этот выбор позволен, но отключен для тестирования. Но если этот выбор позволен во время тестирования, не все отделения достижимы. Поэтому использованию этого выбора времени компиляции препятствуют.

SQLITE_ZERO_MALLOC

Этот выбор опускает распределитель памяти по умолчанию и распределитель памяти отладки и заменяет распределителем памяти, который всегда терпит неудачу. SQLite не будет работать с этим распределителем памяти, так как это будет неспособно ассигновать память. Но этот распределитель может быть заменен во время запуска, используя sqlite3_config( SQLITE_CONFIG_MALLOC,...) или sqlite3_config( SQLITE_CONFIG_HEAP,...). Таким образом, результирующий эффект этого выбора времени компиляции состоит в том, что он позволяет SQLite быть собранным для системной библиотеки, которая не поддерживает malloc(), free() и/или realloc().

10. Анализ и параметры отладки

SQLITE_DEBUG

Исходный код SQLite содержит буквально тысячи assert(), которые раньше проверяли внутренние предположения и предварительные условия подпрограммы и выходные условия. Они обычно выключаются (они не производят код), их включение делает SQLite приблизительно в три раза медленнее. Но для тестирования и анализа, полезно включить assert(). SQLITE_DEBUG делает это.

SQLITE_DEBUG также позволяет некоторые другие функции отладки, такие как специальные запросы PRAGMA, которые включают отслеживание и листинг функций, использованных для поиска неисправностей и анализа VDBE и генератора кода.

SQLITE_MEMDEBUG

SQLITE_MEMDEBUG Выбор SQLITE_MEMDEBUG заставляет инструментованного распределителя памяти отладки использоваться в качестве распределителя памяти по умолчанию в SQLite. Инструментованный распределитель памяти проверяет на неправильное употребление динамично ассигнованной памяти. Примеры неправильного употребления включают использование памяти после того, как это будет освобождено, списывая концы выделения памяти, освобождая память, ранее не полученную распределителя памяти, или будучи не в состоянии инициализировать недавно ассигнованную память.

11. Определенные для Windows варианты

SQLITE_WIN32_HEAP_CREATE

Этот выбор вынуждает Win32 native memory allocator, когда позволено, создать частную кучу, чтобы держать все выделения памяти.

SQLITE_WIN32_MALLOC_VALIDATE

Этот выбор вынуждает Win32 native memory allocator, когда позволено, сделать стратегические вызовы HeapValidate(), если также позволена assert().

12. Связь компилятора и контроль за соглашением о вызовах

Следующий макрос определяет, что интерфейсные детали для определенных видов SQLite собирают. Make-файлы будут обычно обращаться с урегулированием их макросов автоматически. Следующая документация о макросах включена для полноты.

SQLITE_API

Этот макрос определяет внешне видимый интерфейс для SQLite. Этот макрос иногда устанавливается в "extern". Но определение специфично для компилятора.

SQLITE_APICALL

Этот макрос определяет соглашение о вызовах, используемое установленным порядком открытого интерфейса в SQLite, которые принимают постоянное число аргументов. Этот макрос обычно определяется, чтобы быть ничем, хотя на Windows может иногда устанавливаться в "__cdecl" или "__stdcall". Установка "__cdecl" по умолчанию, но "__stdcall" используется, когда SQLite предназначается как системная библиотека Windows.

Единственное объявление функции должно содержать не больше, чем одно из следующего: SQLITE_APICALL, SQLITE_CDECL или SQLITE_SYSAPI.

SQLITE_CALLBACK

Этот макрос определяет соглашение о вызовах, используемое с указателями отзыва в SQLite. Этот макрос обычно определяется, чтобы быть ничем, хотя на Windows может быть "__cdecl" или "__stdcall". По умолчанию "__cdecl", "__stdcall" используется, когда SQLite предназначается как системная библиотека Windows.

SQLITE_CDECL

Этот макрос определяет соглашение о вызовах, используемое установленным порядком интерфейса varargs в SQLite. Этот макрос обычно определяется, чтобы быть ничем, хотя на Windows может иногда устанавливаться в "__cdecl". Этот макрос используется на varargs и не может быть установлен в "__stdcall", так как __stdcall не поддерживает функции varargs.

Единственное объявление функции должно содержать не больше, чем одно из следующего: SQLITE_APICALL, SQLITE_CDECL или SQLITE_SYSAPI.

SQLITE_EXTERN

Этот макрос определяет связь для переменных открытого интерфейса в SQLite. Нужно обычно позволять по умолчанию "extern".

SQLITE_STDCALL

Этот макрос больше не используется и устарел.

SQLITE_SYSAPI

Этот макрос определяет соглашение о вызовах, используемое интерфейсами операционной системы для целевой платформы для SQLite. Этот макрос обычно определяется, чтобы быть ничем, хотя на Windows может иногда устанавливаться в "__stdcall".

Единственное объявление функции должно содержать не больше, чем одно из следующего: SQLITE_APICALL, SQLITE_CDECL или SQLITE_SYSAPI.

SQLITE_TCLAPI

Этот макрос определяет соглашение о вызовах, используемое установленным порядком интерфейса библиотеки TCL. Этот макрос не используется ядром SQLite, только интерфейсом TCL и набором тестов TCL. Этот макрос обычно определяется, чтобы быть ничем, хотя на Windows может иногда устанавливаться в "__cdecl". Этот макрос используется на установленном порядке интерфейса библиотеки TCL, который всегда собирается как __cdecl, даже на платформах, которые предпочитают использовать __stdcall, таким образом, этот макрос не должен быть установлен в __stdcall, если у платформы нет своей библиотеки TCL, которая поддерживает __stdcall.

Этот макрос не может использоваться в сочетании ни с одним из SQLITE_APICALL, SQLITE_CALLBACK, SQLITE_CDECL или SQLITE_SYSAPI.