
WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233	Visa 4274 3200 2453 6495

Small. Fast. Reliable.
Choose any three.

Команды Pragma в SQLite

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

Команда pragma определенная для SQLite и не совместимая ни с каким другим движком базы данных SQL.
Определенные команды pragma могут быть удалены и другие добавлены в будущих выпусках SQLite. Нет никакой гарантии совместимости.
Никакие сообщения об ошибках не произведены, если неизвестный pragma выпущен. Неизвестные pragma просто проигнорированы. Это означает, что если есть опечатка в pragma, библиотека не сообщает пользователю этого факта.
Некоторые pragma вступают в силу во время стадии компиляции SQL, а не на стадии выполнения. Это означает, используя язык C sqlite3_prepare(), sqlite3_step(), sqlite3_finalize() API (или подобный в интерфейсе обертки), pragma может работать во время sqlite3_prepare(), но не sqlite3_step(), как делают нормальные SQL-операторы. Или pragma мог бы работать во время sqlite3_step() точно так же, как нормальные SQL-операторы. Зависят ли pragma во время sqlite3_prepare() или sqlite3_step() от pragma и от определенного выпуска SQLite.
Префиксы EXPLAIN и EXPLAIN QUERY PLAN запросов SQL затрагивают только поведение запроса во время sqlite3_step(). Это означает, что PRAGMA, которые вступают в силу во время sqlite3_prepare(), будут вести себя одинаково, независимо от того, снабжены ли они предисловием "EXPLAIN".

C API SQLite обеспечивает SQLITE_FCNTL_PRAGMA file control, который дает внедрениям VFS возможность добавить новые PRAGMA или отвергнуть значение встроенных.

Командный синтаксис PRAGMA

pragma-stmt:

pragma-value:

signed-number:

pragma может взять или ноль или один аргумент. Аргумент может быть в круглых скобках или он может быть отделен от имени pragma знаком равенства. Эти два синтаксиса приводят к идентичным результатам. Во многих pragma это булево значение. Булевым может быть одно из:

1 yes true on
0 no false off

Аргументы ключевого слова могут произвольно появиться в кавычках. (Пример: 'yes' [FALSE]). Некоторые pragma берут строковый литерал в качестве их аргумента. Когда pragma возьмет аргумент ключевого слова, он будет обычно также брать числовой эквивалент также. Например, "0" и "no" означают то же самое. Запрашивая значение, pragma часто возвращают число, а не ключевое слово.

У pragma может быть дополнительное schema-name перед именем pragma. schema-name это имя БД ATTACH, "main" или "temp" для основной или TEMP БД. Если дополнительное название схемы опущено, "main" подразумевается. В некоторых pragma название схемы бессмысленно и просто проигнорировано. В документации ниже pragma, для которых название схемы значащее, показаны с префиксом "schema.".

Функции PRAGMA

К PRAGMA, которые возвращают результаты и у которых нет побочных эффектов, можно получить доступ от обычных SELECT как к табличным функциям. Для каждого участия PRAGMA у соответствующей табличной функции есть то же самое имя как PRAGMA с 7-символьным префиксом "pragma_". Аргумент PRAGMA и схема, если таковые имеются, передаются как аргументы табличной функции со схемой как дополнительный, последний аргумент.

Например, информация о колонках в индексе может быть прочитана, используя index_info pragma:

PRAGMA index_info('idx52');

Или то же самое содержание может быть прочитано, используя:

SELECT * FROM pragma_index_info('idx52');

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

SELECT DISTINCT m.name || '.' || ii.name AS 'indexed-columns'
       FROM sqlite_schema AS m, pragma_index_list(m.name) AS il,
       pragma_index_info(il.name) AS ii WHERE m.type='table' ORDER BY 1;

Дополнительные примечания:

Табличные функции существуют только для встроенных PRAGMA, не для PRAGMA, определенного, используя контроль за файлом SQLITE_FCNTL_PRAGMA.
Табличные функции существуют только для PRAGMA, которые возвращают результаты и у которых нет побочных эффектов.
Эта функция могла быть использована, чтобы осуществить information schema первым созданием отдельного использования схемы
```
ATTACH ':memory:' AS 'information_schema';
```
Затем создавая VIEW в той схеме, которые осуществляют официальные таблицы информационной схемы, используя табличные функции PRAGMA.
Табличные функции для особенности PRAGMA были добавлены в версии SQLite version 3.16.0 (2017-01-02). Предыдущие версии SQLite не могут использовать эту функцию.

Список всех PRAGMA

Примечания:

Pragma, имена ~~которых зачеркнуты~~, удерживаются от использования. Не используйте их. Они существуют для совместимости.
Эти pragmas доступны только в сборках, использующих нестандартные варианты времени компиляции.
Эти pragma используются для тестирования SQLite и не рекомендуются для использования в прикладных программах.

PRAGMA analysis_limit;
PRAGMA analysis_limit = N;

Запросите или измените ограничение на approximate ANALYZE. Это приблизительное количество строк, исследованных в каждом индексе командой ANALYZE. Если аргумент N опущен, то аналитический предел неизменен. Если предел 0, то аналитический предел отключен, и команда ANALYZE исследует все строки каждого индекса. Если N больше, чем ноль, то аналитический предел устанавливается в N, и последующие команды ANALYZE прекратят анализировать каждый индекс после того, как это исследовало приблизительно N строк. Если N отрицательное число или что-то другое, чем целочисленное значение, то pragma ведет себя, как будто аргумент N был опущен. Во всех случаях возвращенное значение является новым аналитическим пределом, используемым для последующих команд ANALYZE.

Этот pragma может использоваться, чтобы помочь команде ANALYZE работать быстрее на больших базах данных. Результаты анализа не так хороши, когда только часть каждого индекса исследована, но результаты обычно достаточно хороши. Урегулирование N к 100 или 1000 позволяет команде ANALYZE работать очень быстро, даже на файлах базы данных в несколько гигабайт. Этот pragma особенно полезен в сочетании с PRAGMA optimize.

Этот pragma был добавлен в версии 3.32.0 (2020-05-22). Текущее внедрение использует только первые 31 бита значения N, биты высшего порядка тихо проигнорированы. Будущие версии SQLite могли бы начать использовать биты высшего порядка. PRAGMA application_id

PRAGMA schema.application_id;
PRAGMA schema.application_id = integer ;

application_id PRAGMA используется, чтобы запросить или установить 32-bit signed big-endian "Application ID" integer, расположенное в смещении 68 в заголовке БД. Запросы, которые используют SQLite в качестве их прикладного формата файла, должны установить целое число идентификатора приложения в уникальное целое число так, чтобы утилиты, такие как file(1), могли определить тип файла вместо того, чтобы просто сообщить "о Базе данных SQLite3". Список назначенных идентификаторов приложений может быть найден, консультируясь с файлом magic.txt в исходном хранилище SQLite.

См. также user_version pragma. PRAGMA auto_vacuum

Запрос или установка статуса auto-vacuum в БД.

Настройка по умолчанию для auto-vacuum = 0 или "none", если выбор времени компиляции SQLITE_DEFAULT_AUTOVACUUM использован. Значение "none" отключает auto-vacuum. Когда auto-vacuum выключен, и данные удалены из базы данных, файл базы данных остается того же самого размера. Неиспользованные страницы файла базы данных добавляются к "freelist" и снова используются для последующих вставок. Таким образом, никакое файловое пространство базы данных не потеряно. Однако, файл базы данных не сжимается. В этом режиме команда VACUUM может использоваться, чтобы восстановить весь файл базы данных и таким образом вернуть неиспользуемое пространство диска.

Когда auto-vacuum = 1 или "full", список свободных страниц перемещен до конца файла базы данных, и файл базы данных усечен, чтобы удалить freelist в каждой транзакции. Отметьте, однако, что автовакуум только усекает страницы freelist. Автовакуум не дефрагментирует базу данных и не перепакует отдельные страницы БД, как делает команда VACUUM. На самом деле, потому что это перемещает страницы в файле, автовакуум может на самом деле сделать фрагментацию хуже.

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

Когда значение auto-vacuum = 2 или "incremental", дополнительная информация должна быть сохраненав файле базы данных, но auto-vacuuming не происходит автоматически в каждой передаче, как это делается с auto_vacuum=full. В возрастающем режиме отдельный incremental_vacuum pragma должен быть вызван, чтобы заставить автовакуум происходить.

Соединение с базой данных может быть изменено между полным и возрастающим автовакуумным режимом в любое время. Однако, изменение с "none" на "full" или "incremental" может произойти только, когда база данных новая (никакие таблицы еще не были составлены) или управляя командой VACUUM. Чтобы изменить автовакуумные режимы, сначала используйте auto_vacuum pragma, чтобы установить новый желаемый режим, затем вызовите команду VACUUM, чтобы реорганизовать весь файл базы данных. Изменение с "full" или "incremental" на "none" всегда требует VACUUM даже на пустой базе данных.

Когда auto_vacuum pragma вызван без аргументов, он возвращает текущее значение auto_vacuum.

PRAGMA automatic_index;
PRAGMA automatic_index = boolean;

Запросить, установить или сбросить automatic indexing.

Automatic indexing включен по умолчанию с version 3.7.17 (2013-05-20), но это могло бы измениться в будущих выпусках SQLite. PRAGMA busy_timeout

PRAGMA busy_timeout;
PRAGMA busy_timeout = milliseconds;

Запросите или измените настройки busy timeout. Этот pragma альтернатива sqlite3_busy_timeout(), который сделан доступным как pragma для использования с привязками к языку, которые не обеспечивают прямой доступ к sqlite3_busy_timeout().

У каждого соединения с базой данных может быть только единственный busy handler. Этот PRAGMA устанавливает дескриптор для процесса, возможно переписывая любой ранее заданный дескриптор. PRAGMA cache_size

PRAGMA schema.cache_size;
PRAGMA schema.cache_size = pages;
PRAGMA schema.cache_size = -kibibytes;

Запросите или измените предложенное максимальное количество дисковых страниц базы данных, которые SQLite будет держать в памяти сразу на открытый файл базы данных. Соблюдают ли это предложение, на усмотрение Application Defined Page Cache. Кэш страницы по умолчанию, который встроен в SQLite, соблюдает запрос, однако альтернативные определенные применением внедрения кэша страницы могут интерпретировать предложенный размер кэша по-разному или игнорируют все это По умолчанию размер -2000, что означает, что размер кэша ограничивается 2048000 байтами памяти. По умолчанию размер кэша может быть изменен, используя варианты времени компиляции SQLITE_DEFAULT_CACHE_SIZE. БД TEMP имеет по умолчанию предложенный размер кэша 0 страниц.

Если аргумент N положительный, предложенный размер кэша установлен в N. Если аргумент N отрицателен, то количество страниц кэша подогнано, чтобы использовать примерно abs(N*1024) байт памяти на основе текущего размера страницы. SQLite помнит число страниц в кэше страницы, а не используемый объем памяти. Таким образом, если вы установите размер кэша, используя отрицательное число и впоследствии измените размер страницы (используя PRAGMA page_size), то максимальная сумма кэш-памяти изменится в пропорции к изменению в размере страницы.

Примечание совместимости: поведение cache_size с отрицательным N отличалось до version 3.7.10 (2012-01-16). В более ранних версиях число страниц в кэше было определено к абсолютному значению N.

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

Кэш страницы по умолчанию не ассигнует полный объем кэш-памяти внезапно. Кэш-память ассигнуется в меньших кусках по мере необходимости. Урегулирование page_cache это (предложенная) верхняя граница на объем памяти, который кэш может использовать, не на объем памяти, который это будет использовать все время. Это поведение внедрения кэша страницы по умолчанию, но application defined page cache свободен вести себя по-другому. PRAGMA cache_spill

PRAGMA cache_spill;
PRAGMA cache_spill=boolean;
PRAGMA schema.cache_spill=N;

cache_spill pragma позволяет или отключает возможность перенести грязные страницы кэша к файлу базы данных посреди транзакции. Cache_spill позволен по умолчанию, и большинство запросов должно оставить его таким, поскольку перенос кэша обычно выгоден. Однако у него есть побочный эффект приобретения блокировки EXCLUSIVE на файле базы данных. Следовательно, некоторые запросы, у которых есть большие продолжительные транзакции, могут хотеть отключить перенос кэша, чтобы препятствовать приобрести монопольную блокировку на базе данных до момента COMMITs.

Форма "PRAGMA cache_spill=N" устанавливает минимальный порог размера кэша, требуемый для переноса. Число страниц в кэше должно превысить порог cache_spill и максимальный размер кэша, установленный PRAGMA cache_size.

Форма "PRAGMA cache_spill=boolean" применяется через все базы данных, приложенные к соединению с базой данных. Но форма "PRAGMA cache_spill=N" этого запроса относится только к схеме "main" независимо от того, что другая схема определяется как часть запроса. PRAGMA case_sensitive_like

PRAGMA case_sensitive_like = boolean;

Поведение по умолчанию оператора LIKE должно проигнорировать регистр для знаков ASCII. Следовательно, по умолчанию 'a' LIKE 'A' = true. case_sensitive_like pragma устанавливает новую определенную применением функцию LIKE, которая является или чувствительной к регистру или нечувствительной в зависимости от case_sensitive_like pragma. Когда case_sensitive_like выключен, работает поведение LIKE по умолчанию. Когда case_sensitive_like включен, регистр становится значительным. Так, например, 'a' LIKE 'A' = false, но 'a' LIKE 'a' = true.

Этот pragma использует sqlite3_create_function(), чтобы перегрузить LIKE и функции GLOB, которые могут отвергнуть предыдущие внедрения LIKE и GLOB, зарегистрированные применением. Этот pragma изменяет только поведение оператора SQL LIKE. Это не изменяет поведение sqlite3_strlike(), который является всегда нечувствительным к регистру.

ПРЕДУПРЕЖДЕНИЕ: Если база данных использует оператора LIKE где-нибудь в схеме, например, в ограничении CHECK, индексе выражения или в операторе Where частичного индекса, то изменение определения оператора LIKE, использующего этот PRAGMA, может заставить базу данных казаться поврежденной. PRAGMA integrity_check сообщит об ошибках. База данных действительно не повреждена, изменение поведения LIKE назад к режиму, в котором это было, когда схема была определена, и база данных была наполнена, очистит проблему. Если использование LIKE происходит только в индексах, то проблема может быть очищена, управляя REINDEX. Тем не менее, использованию case_sensitive_like pragma препятствуют.

Этот pragma удерживается от использования и существует только для обратной совместимости. Новые запросы должны избегать использования этого pragma. Более старые запросы должны прекратить использование этого pragma при первой возможности. Этот pragma может быть не собран, когда SQLite собран, используя SQLITE_OMIT_DEPRECATED.

PRAGMA cell_size_check
PRAGMA cell_size_check = boolean;

cell_size_check pragma позволяет или отключает дополнительную проверку страниц b-дерева базы данных, когда они первоначально прочитаны с диска. С позволенной проверкой размера ячейки повреждение базы данных обнаружено ранее и менее вероятно распространится. Однако, есть маленький исполнительный хит для того, чтобы сделать дополнительные проверки и таким образом, проверка размера ячейки выключена по умолчанию. PRAGMA checkpoint_fullfsync

PRAGMA checkpoint_fullfsync
PRAGMA checkpoint_fullfsync = boolean;

Запросите или измените флаг fullfsync для checkpoint. Если этот флаг установлен, то метод синхронизации F_FULLFSYNC используется во время операций по контрольной точке на системах с поддержкой F_FULLFSYNC. Значение по умолчанию флага checkpoint_fullfsync = off. Только Mac OS X поддерживает F_FULLFSYNC.

Если fullfsync установлен, метод синхронизации F_FULLFSYNC используется для всех синхронизирующих операций, и урегулирование checkpoint_fullfsync не важно.

PRAGMA collation_list;

Возвратите список последовательностей сопоставления, определенных для текущего соединения с базой данных.

PRAGMA compile_options;

Этот pragma возвращает названия compile-time options, используемых при сборке SQLite, по опции на строку. Префикс "SQLITE_" опущен у возвращенных имен выбора. См. также sqlite3_compileoption_get() и sqlite_compileoption_get().

PRAGMA count_changes;
PRAGMA count_changes = boolean;

Запросите или измените флаг изменений количества. Обычно когда флаг изменений количества не установлен, INSERT, UPDATE и DELETE не возвращают данных. Когда изменения количества установлены, каждая из этих команд возвращает единственную строку данных, состоящую из одного целочисленного значения, количества строк, вставленных, измененных или удаленных командой. Возвращенное количество изменений не включает вставок, модификаций или удалений, выполненных триггерами, никакие изменения, внесенные автоматически действиями внешнего ключа, или обновления вызванные upsert.

Другой путь получить количество изменений строки состоит в том, чтобы использовать sqlite3_changes() или sqlite3_total_changes(). Есть тонкое различие. Когда INSERT, UPDATE или DELETE управляют против представления, используя триггер INSTEAD OF, count_changes pragma сообщает о количестве строк в представлении, которые запустили триггер, тогда как sqlite3_changes() и sqlite3_total_changes() этого не делают.

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

PRAGMA data_store_directory;
PRAGMA data_store_directory = 'directory-name';

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

Изменение настроек data_store_directory не ориентировано на многопотоковое исполнение. Никогда не изменяйте настройки data_store_directory, если другой поток в применении управляет каким-либо интерфейсом SQLite в то же время. Это приводит к неопределенному поведению. Изменение настроек data_store_directory пишет глобальную переменную sqlite3_data_directory, а эта глобальная переменная не защищена mutex.

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

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

PRAGMA schema.data_version;

"PRAGMA data_version" обеспечивает признак, что файл базы данных был изменен. Интерактивные программы, которые держат содержание базы данных в памяти, могут использовать PRAGMA data_version, чтобы определить, должны ли они перезагрузить свою память или обновить отображение на экране.

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

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

PRAGMA database_list;

Этот pragma работает как запрос, чтобы возвратить одну строку для каждой базы данных, приложенной к текущему соединению с базой данных. Вторая колонка "main" для главного файла базы данных, "temp" для файла базы данных объектов TEMP или название базы данных ATTACH для других файлов базы данных. Третья колонка это название самого файла базы данных или пустая строка, если база данных не связана с файлом.

PRAGMA schema.default_cache_size;
PRAGMA schema.default_cache_size = Number-of-pages;

Этот pragma запрашивает или определяет предложенное максимальное число страниц дискового кэша, которые будут ассигнованы на открытый файл базы данных. Различие между этим pragma и cache_size в том, что набор значений здесь сохраняется через соединения с базой данных. Значение размера кэша по умолчанию сохранено в 4-байтовом целом числе с обратным порядком байтов, расположенном в смещении 48 в заголовке файла базы данных.

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

PRAGMA defer_foreign_keys
PRAGMA defer_foreign_keys = boolean;

Когда defer_foreign_keys PRAGMA = on, осуществление всех ограничений внешнего ключа отложено, пока наиболее удаленная транзакция не передается. defer_foreign_keys pragma по умолчанию OFF так, чтобы ограничения внешнего ключа были только отсрочены, если они создаются как "DEFERRABLE INITIALLY DEFERRED". defer_foreign_keys pragma автоматически выключен в каждом COMMIT или ROLLBACK. Следовательно, defer_foreign_keys pragma должен быть отдельно позволен для каждой транзакции. Этот pragma значащий только если ограничения внешнего ключа позволены, конечно.

sqlite3_db_status(db, SQLITE_DBSTATUS_DEFERRED_FKS,...) может использоваться во время транзакции, чтобы определить, отсрочены ли там нерешенные ограничения внешнего ключа.

PRAGMA empty_result_callbacks;
PRAGMA empty_result_callbacks = boolean;

Запросите или измените флаг пустых отзывов результата.

Флаг empty-result-callbacks затрагивает только sqlite3_exec() API. Обычно, когда флаг пустых отзывов результата очищен, функция обратного вызова, поставляемая sqlite3_exec(), не вызвана для команд, которые возвращают нулевые строки данных. Когда пустые отзывы результата установлены в этой ситуации, функция обратного вызова вызвана точно однажды с третьим параметром 0 (NULL). Это должно позволить программы, которые используют sqlite3_exec() API, восстановить имена столбцов, даже когда запрос не возвращает данных.

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

PRAGMA encoding;
PRAGMA encoding = 'UTF-8';
PRAGMA encoding = 'UTF-16';
PRAGMA encoding = 'UTF-16le';
PRAGMA encoding = 'UTF-16be';

В первой форме, если главная база данных была уже создана, то этот pragma возвращает текстовое кодирование, используемое главной базой данных, одно из 'UTF-8', 'UTF-16le' (UTF-16 с прямым порядком байтов) или 'UTF-16be' (UTF-16 с обратным порядком байтов). Если главная база данных не была создана, то возвращенное значение является текстом, кодирующим, которая кодировка будет использоваться, чтобы создать главную базу данных, если это будет создано этой сессией.

Формы со второй по пятую этого pragma устанавливают кодировку, в которой главная база данных будет создана, если это будет создано этой сессией. Последовательность 'UTF-16' интерпретируется как "UTF-16 с использованием родного машинного порядка байтов". Невозможно изменить текстовое кодирование базы данных после того, как это было создано, и любая попытка сделать так будет тихо проигнорирована.

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

Как только кодирование было установлено для базы данных, оно не может быть изменено.

Базы данных, созданные командой ATTACH, всегда используют то же самое кодирование, как у главной базы данных. Попытка ATTACH базы данных с текстовым кодированием, отличным от "главной" базы данных потерпит неудачу.

PRAGMA schema.foreign_key_check;
PRAGMA schema.foreign_key_check(table-name);

foreign_key_check pragma проверяет базу данных или таблицу "table-name" на ограничения внешнего ключа, которые нарушены. foreign_key_check pragma возвращает одну строку для каждого нарушения внешнего ключа. В каждой строке результата есть четыре колонки. Первая колонка название таблицы, которая содержит пункт REFERENCES. Вторая колонка rowid строки, которая содержит пункт REFERENCES, или NULL, если дочерняя таблица WITHOUT ROWID. Третья колонка название таблицы, которая упомянута. Четвертая колонка индекс определенного ограничения внешнего ключа, которое потерпело неудачу. Четвертая колонка в выводе foreign_key_check pragma тот же integer, как первая колонка в выводе foreign_key_list pragma. Когда "table-name" определяется, единственные проверенные ограничения внешнего ключа являются созданными пунктами REFERENCES в CREATE TABLE для table-name.

PRAGMA foreign_key_list(table-name);

Этот pragma возвращает одну строку для каждого ограничения внешнего ключа, созданного пунктом REFERENCES в запросе CREATE TABLE для таблицы "table-name". PRAGMA foreign_keys

PRAGMA foreign_keys;
PRAGMA foreign_keys = boolean;

Запрашивает, устанавливает или очищает ограничения внешнего ключа.

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

Изменение урегулирования foreign_keys затрагивает выполнение всех запросов, подготовленных, используя соединение с базой данных, включая подготовленные прежде, чем настройки были изменены. Любые существующие запросы, подготовленные через sqlite3_prepare(), могут потерпеть неудачу с ошибкой SQLITE_SCHEMA после того, как настройки foreign_keys изменяются.

С SQLite version 3.6.19 настройка по умолчанию для осуществления внешнего ключа OFF. Однако это могло бы измениться в будущем выпуске SQLite. Настройка по умолчанию для осуществления внешнего ключа может быть определена во время компиляции, используя макрос препроцессора SQLITE_DEFAULT_FOREIGN_KEYS. Чтобы минимизировать будущие проблемы, запросы должны установить флаг осуществления внешнего ключа как требуется применением и не зависеть от настройки по умолчанию. PRAGMA freelist_count

PRAGMA schema.freelist_count;

Возвратите число неиспользованных страниц в файле базы данных.

PRAGMA full_column_names;
PRAGMA full_column_names = boolean;

Запросите или измените флаг full_column_names. Этот флаг вместе с short_column_names определяет режим, которым SQLite назначает имена столбцам результата SELECT. Столбцы результата называют, применяя следующие правила:

Если есть пункт AS на результате, то название колонки это правая сторона пункта AS.
Если результат общее выражение, не просто название исходного столбца таблицы, то название результата это копия текста выражения.
Если short_column_names pragma = ON, то название результата это название исходного столбца таблицы без исходного префикса имени таблицы.
Если обе прагмы short_column_names и full_column_names = OFF, применен вариант (2).
Название столбца результата это комбинация исходного столбца таблицы и имени столбца источника: TABLE.COLUMN

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

PRAGMA fullfsync
PRAGMA fullfsync = boolean;

Запросите или измените флаг fullfsync. Этот флаг определяет, используется ли метод синхронизации F_FULLFSYNC на системах, которые поддерживают его. Значение по умолчанию флага fullfsync off. Только Mac OS X поддерживает F_FULLFSYNC.

См. также: checkpoint_fullfsync.

PRAGMA function_list;

Этот pragma возвращает список из функций SQL, известных соединению с базой данных. Каждая строка результата описывает единственную сигнатуру запроса для единственной функции SQL. У некоторых функций SQL будут многократные строки в наборе результатов, если они могут (например) быть вызваны с переменным количеством аргументов или могут принять текст в различном кодировании. PRAGMA hard_heap_limit

PRAGMA hard_heap_limit
PRAGMA hard_heap_limit=N

Этот pragma вызовает sqlite3_hard_heap_limit64() с аргументом N, если N определяется и это положительное целое число, которое меньше, чем текущий строгий предел кучи. hard_heap_limit pragma всегда возвращает то же самое целое число, которое было бы возвращено sqlite3_hard_heap_limit64(-1). То есть это всегда возвращает значение жесткого предела кучи, который устанавливается после любых изменений, наложенных этим PRAGMA.

Этот pragma может только понизить предел кучи, никогда не поднимать его. Интерфейс языка C sqlite3_hard_heap_limit64() должен использоваться, чтобы повысить предел кучи.

См. также soft_heap_limit pragma. PRAGMA ignore_check_constraints

PRAGMA ignore_check_constraints = boolean;

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

PRAGMA schema.incremental_vacuum(N);
PRAGMA schema.incremental_vacuum;

incremental_vacuum pragma вызывает до N страниц, которые будут удалены из freelist. Файл базы данных усечен. incremental_vacuum pragma не имеет никакого эффекта, если база данных не находится в режиме auto_vacuum=incremental или при отсутствии страниц в freelist. Если есть меньше, чем N страниц в freelist, если N меньше 1 или аргумент "(N)" опущен, то весь freelist очищен.

PRAGMA schema.index_info(index-name);

Этот pragma возвращает одну строку для каждого столбца ключа в названном индексе. Столбец ключа это колонка, которую на самом деле называют в запросе индекса CREATE INDEX, ограничении UNIQUE или ограничении PRIMARY KEY, которое создало индекс. Элементы индекса также обычно содержат вспомогательные колонки, которые указывают назад на внесенную в указатель строку таблицы. Вспомогательные столбцы индекса не показывает index_info pragma, но они перечисляются index_xinfo pragma.

Колонки вывода index_info pragma следующие:

Разряд колонки в индексе (0 означает крайний левый).
Разряд колонки во внесенной в указатель таблице. Значение -1 указывает rowid, значение -2 выражение используется.
Название колонки внесено в указатель. Эта колонка NULL, если колонка rowid или expression.

Если нет никакого индекса, названного index-name, но есть таблица WITHOUT ROWID с тем именем, то (с SQLite version 3.30.0 on 2019-10-04) этот pragma возвращает колонки таблицы PRIMARY KEY WITHOUT ROWID, поскольку они используются в отчетах основного b-дерева, которое связано с удаленными колонками-дубликатами. PRAGMA index_list

PRAGMA schema.index_list(table-name);

Этот pragma возвращает одну строку для каждого индекса, связанного с данной таблицей. Колонки вывода index_list pragma:

Порядковый номер, назначенный на каждый индекс во внутренних целях отслеживания.
Название индекса.
"1", если индекс UNIQUE и "0" если нет.
"c", если индекс был создан запросом CREATE INDEX, "u", если индекс был создан ограничением UNIQUE или "pk", если индекс был создан ограничением PRIMARY KEY.
"1", если индекс частичный и "0" иначе.

PRAGMA schema.index_xinfo(index-name);

Этот pragma возвращает информацию о каждой колонке в индексе. В отличие от index_info pragma, этот pragma возвращает информацию о каждой колонке в индексе, не только столбцы ключа. Столбец ключа это колонка, которую на самом деле называют в запросе индекса CREATE INDEX, ограничении UNIQUE или ограничении PRIMARY KEY, которое создало индекс. Вспомогательные колонки это дополнительные колонки, чтобы определить местонахождение записи таблицы, которая соответствует каждому элементу индекса.

Колонки вывода index_xinfo pragma:

Разряд колонки в индексе (0 означает крайний левый. Столбцы ключа перед вспомогательными колонками).
Разряд колонки в таблице, внесенной в указатель, -1, если столбец индекса rowid внесенной в указатель таблицы, или -2, если индекс находится по выражению.
Название колонки, внесенной в указатель, NULL, если столбец индекса rowid внесенной в указатель таблицы или выражение.
1, если столбец индекса сортирован наоборот (DESC) индексом и 0 иначе.
Название последовательности сопоставления для сравнения значений в столбце индекса.
1, если столбец индекса это столбец ключа и 0, если столбец индекса это вспомогательная колонка.

Если нет никакого индекса, названного index-name, но есть таблица WITHOUT ROWID с тем именем, то (с SQLite version 3.30.0 on 2019-10-04) этот pragma возвращает колонки таблицы WITHOUT ROWID, поскольку они используются в отчетах основного b-дерева, которое применяется при дедупликации столбцов PRIMARY KEY, сначала сопровождаемых столбцами данных. PRAGMA integrity_check

PRAGMA schema.integrity_check;
PRAGMA schema.integrity_check(N)
PRAGMA schema.integrity_check(TABLENAME )

Этот pragma делает форматирование низкого уровня и проверку на непротиворечивость базы данных. integrity_check pragma ищет:

Записи таблицы или элементы индекса, которые вне последовательности
Неформатные записи
Недостающие страницы
Пропавшие без вести или избыточные элементы индекса
Ошибки ограничений UNIQUE, CHECK и NOT NULL
Целостность freelist
Разделы базы данных, которые используются несколько раз или ни одного

Если integrity_check pragma находит проблемы, последовательности возвращены (как многократные строки с отдельным столбцом на строку), которые описывают проблемы. Pragma integrity_check возвратит минимум N ошибок, прежде чем завершит анализ. По умолчанию 100. Если pragma integrity_check не находит ошибок, возвращает единственную строку со значением 'ok'.

Обычный случай: то, что весь файл базы данных проверяется. Однако, если есть аргумент TABLENAME, то выполняется только проверка для названной таблицы и связанных индексов. Это называют "частичной проверкой целостности". Поскольку проверяется только подмножество базы данных, такие ошибки, как неиспользованные разделы файла или использование того же самого раздела файла двумя или больше таблицами, не могут быть обнаружены. freelist проверяется на частичной проверке целостности только если TABLENAME это sqlite_schema или один из его псевдонимов. Поддержка частичных проверок целостности была добавлена с версии version 3.33.0 (2020-08-14).

PRAGMA integrity_check не находит ошибки FOREIGN KEY. Используйте PRAGMA foreign_key_check, чтобы найти ошибки в ограничениях FOREIGN KEY.

См. также PRAGMA quick_check, которая делает большую часть проверки PRAGMA integrity_check, но работает намного быстрее.

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

Первая форма этого pragma запрашивает текущий режим журнала для database. Когда database опущена, подразумевается "main".

Вторая форма изменяет режим журнала для "database" или для всех приложенных баз данных, если "database" опущена. Новый режим журнала возвращен. Если режим журнала не мог быть изменен, оригинальный режим журнала возвращен.

Режим DELETE является нормальным поведением. В режиме DELETE журнал обратной перемотки удален в конце каждой транзакции. Действительно, операция удаления это действие, которое заставляет транзакцию передавать. См. здесь подробности.

Режим TRUNCATE передает транзакции, усекая журнал обратной перемотки к нулевой длине вместо того, чтобы удалить его. На многих системах, усечение файла намного быстрее, чем удаление, так как содержание каталога не должно быть изменено.

Режим PERSIST препятствует тому, чтобы журнал обратной перемотки был удален в конце каждой транзакции. Вместо этого заголовок журнала переписан нолями. Это будет препятствовать тому, чтобы другие соединения с базой данных откатили журнал до прежнего уровня. PERSIST полезен как оптимизация на платформах, где удаление или усечение файла намного более дорогие, чем переписывание первого блока файла нолями. См. также: PRAGMA journal_size_limit и SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT.

Режим MEMORY хранит журнал обратной перемотки в RAM. Это экономит дисковый I/O, но за счет безопасности базы данных и целостности. Если применение, используя SQLite, потерпит крах посреди транзакции, когда режим MEMORY будет установлен, то файл базы данных очень вероятно повредится.

Режим WAL использует журнал с упреждающей записью вместо журнала обратной перемотки, чтобы осуществить транзакции. WAL-режим постоянный, будучи установленным это остается в действительности через многократные соединения с базой данных и после закрытия и повторного открытия базы данных. К базе данных в WAL-режиме может получить доступ только SQLite version 3.7.0 (2010-07-21) или позже.

Режим OFF отключает журнал обратной перемотки полностью. Никакой журнал обратной перемотки никогда не создается и следовательно никогда нет журнала обратной перемотки, чтобы удалить. OFF отключает атомный коммиты и возможности обратной перемотки SQLite. Команда ROLLBACK больше не работает, это ведет себя неопределенно. Запросы должны избегать использования ROLLBACK, когда режим журнала OFF. Если происходит сбой приложения посреди транзакции, когда режим OFF будет установлен, то файл базы данных очень вероятно поврежден. Без журнала нет никакого пути, чтобы раскрутить частично завершенные операции после ограничительной ошибки. Это могло бы также оставить базу данных в непоследовательном состоянии. Например, если двойной вход заставит CREATE UNIQUE INDEX терпеть неудачу на полпути, это оставит частично созданный и следовательно неправильный индекс. Поскольку режим OFF позволяет файлу базы данных быть испорченным, используя обычный SQL, это отключено, когда включен SQLITE_DBCONFIG_DEFENSIVE.

Обратите внимание на то, что journal_mode для базы данных в памяти это MEMORY или OFF и не может быть изменен на иное значение. Попытка изменить journal_mode базы данных в памяти к любому урегулированию кроме MEMORY или OFF проигнорирована. Отметьте также, что journal_mode не может быть изменен в то время, как транзакция активна.

PRAGMA schema.journal_size_limit
PRAGMA schema.journal_size_limit = N ;

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

Точно так же в режиме WAL файл журнала с упреждающей записью не усечен следующей checkpoint. Вместо этого SQLite снова использует существующий файл для последующих записей WAL, так как переписывание быстрее, чем добавление.

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

Вторая форма упомянутого выше pragma используется, чтобы установить новый предел в байтах для указанной базы данных. Отрицательное число не подразумевает предела. Чтобы всегда усечь журналы обратной перемотки и файлы WAL к их минимальному размеру, установите journal_size_limit = 0. Первая и вторая формы pragma выше возвращают единственную строку результата, содержащую единственную колонку целого числа: значение ограничения размера журнала в байтах. Предел размера журнала по умолчанию -1 (никакой предел). Макрос препроцессора SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT может использоваться, чтобы изменить предел размера журнала по умолчанию во время компиляции.

Этот pragma воздействует только на единую базу данных, определенную до имени pragma (на "main", если никакая база данных не определяется). Нет никакого способа изменить ограничение размера журнала на все приложенные базы данных, используя единственный запрос PRAGMA. Предел размера должен быть установлен отдельно для каждой приложенной базы данных. PRAGMA legacy_alter_table

PRAGMA legacy_alter_table;
PRAGMA legacy_alter_table = boolean

Этот pragma устанавливает или запрашивает значение legacy_alter_table. Когда этот флаг on, ALTER TABLE RENAME (для того, чтобы изменить название таблицы) работает как это сделало в SQLite 3.24.0 (2018-06-04) и раньше. Более определенно, когда этот флаг on, ALTER TABLE RENAME только переписывает начальное возникновение имени таблицы в запросе CREATE TABLE и в любых связанных запросах CREATE INDEX и CREATE TRIGGER. Другие ссылки на таблицу не изменяются, включая:

Ссылки на таблицу в корпусах триггеров и обзоров.
Ссылки на таблицу в ограничениях CHECK в оригинальном запросе CREATE TABLE.
Ссылки на таблицу в операторах Where частичных индексов.

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

Этот pragma обеспечивается для более старых программ, которые содержат код, который ожидает неполное поведение ALTER TABLE RENAME в более старых версиях SQLite. Новые запросы должны оставить этот флаг выключенным.

Для совместимости с более старыми виртуальными таблицами этот флаг включен временно, в то время как работает метод sqlite3_module.xRename. Значение этого флага восстановлено после того, как метод sqlite3_module.xRename завершен.

Старая логика alter table также может быть включена использованием выбора SQLITE_DBCONFIG_LEGACY_ALTER_TABLE в sqlite3_db_config().

Старая логика alter table своя для каждого подключения. Включение этого влияет на все приложенные файлы базы данных в рамках соединения с БД. Урегулирование не сохраняется. Изменение этих настроек в одной связи не затрагивает никакие другие связи. PRAGMA legacy_file_format

PRAGMA legacy_file_format;

Этот pragma больше не функционирует. Возможности, раньше обеспеченные PRAGMA legacy_file_format, являются теперь доступными через использование выбора SQLITE_DBCONFIG_LEGACY_FILE_FORMAT в sqlite3_db_config().

PRAGMA locking_mode

PRAGMA schema.locking_mode;
PRAGMA schema.locking_mode=NORMAL | EXCLUSIVE

Этот pragma устанавливает или запрашивает режим блокировки соединения с базой данных. Режим блокировки NORMAL или EXCLUSIVE.

В NORMAL (умолчание, если не отвергнуто во время компиляции используя SQLITE_DEFAULT_LOCKING_MODE), соединение с базой данных открывает файл базы данных в конце каждой транзакции чтения или записи. Когда режим блокировки установлен в EXCLUSIVE, соединение с базой данных никогда не выпускает блокировку файла. В первый раз, когда база данных прочитана в режиме EXCLUSIVE, коллективная блокировка получена. В первый раз, когда база данных написана, монопольная блокировка получена.

Блокировки базы данных, полученные связью в режиме EXCLUSIVE, могут быть выпущены закрыв соединение с базой данных или установив режим блокировки NORMAL, используя этот pragma и затем получив доступ к файлу базы данных (для чтения или записи). Просто урегулирование режима блокировки к NORMAL недостаточно: блокировки не выпущены до следующего получения доступа к файлу базы данных.

Есть три причины установить режим блокировки в EXCLUSIVE.

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

Когда locking_mode pragma определяет конкретную базу данных, например:

PRAGMA main.locking_mode=EXCLUSIVE;

режим блокировки применяется только к названной базе данных. Если никакой определитель имени базы данных не предшествует ключевому слову "locking_mode", режим блокировки применяется ко всем базам данных, включая любые новые базы данных, добавленные последующими командами ATTACH.

БД "temp" (в которой сохранены таблицы TEMP и индексы) и БД в памяти всегда использует исключительный режим блокировки. Режим блокировки temp и БД в памяти не может быть изменен. Все другие базы данных используют нормальный режим блокировки по умолчанию и затронуты этим pragma.

Если режим блокировки EXCLUSIVE, при первом включении режима WAL режим блокировки не может быть изменен на NORMAL до окончания режима журнала WAL. Если режим блокировки NORMAL, при первом включении режима WAL режим блокировки может быть изменен между NORMAL и EXCLUSIVE и назад в любое время без выхода из режима журнала WAL.

PRAGMA schema.max_page_count;
PRAGMA schema.max_page_count = N;

Запрашивает или задает максимальное число страниц в файле базы данных. Обе формы pragma возвращают максимальное количество страниц. Вторая форма пытается изменить максимальное количество страниц. Максимальное количество страниц не может быть уменьшено ниже текущего размера базы данных.

PRAGMA schema.mmap_size;
PRAGMA schema.mmap_size=N

Запросить или изменить максимальное количество байтов, которые обойдены для I/O с отображенной памятью на единой базе данных. Первая форма (без аргумента) запрашивает текущий предел. Вторая форма (с числовым аргументом) устанавливает предел для указанной базы данных или для всех баз данных, если дополнительное имя базы данных опущено. Во второй форме, если имя базы данных опущено, предел, который устанавливается, становится пределом по умолчанию для всех баз данных, которые добавляются к соединению с БД командами ATTACH.

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

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

Размер региона I/O с отображенной памятью не может быть изменен в то время, как регион I/O с отображенной памятью в активном употреблении, чтобы не отображать память из-под управления SQL-операторами. Поэтому mmap_size pragma может ничего не сделать, если предшествующий mmap_size отличный от нуля и есть другие SQL-операторы, работаюшие одновременно на том же самом соединении с БД.

PRAGMA module_list;

Этот pragma возвращает список модулей виртуальных таблиц, зарегистрированных в соединении с базой данных. PRAGMA optimize

PRAGMA optimize;
PRAGMA optimize(MASK);
PRAGMA schema.optimize;
PRAGMA schema.optimize(MASK);

Попытка оптимизировать базу данных. Все схемы оптимизированы в первых двух формах, и только указанная схема оптимизирована в последних двух.

Чтобы достигнуть лучшей долгосрочной производительности запросов без потребности сделать подробный технический анализ прикладной схемы и SQL, рекомендуется выполнять "PRAGMA optimize" (без аргументов) прежде, чем закрыть каждое соединение с БД. Продолжительные запросы могли бы также извлечь выгоду из выполнения "PRAGMA optimize" каждые несколько часов.

Этот pragma обычно очень быстр. Однако, если SQLite чувствует, что выполнение оптимизации базы данных (например, запуск ANALYZE или создание новых индексов) улучшит исполнение будущих запросов, тогда некоторый I/O базы данных может быть сделан. Запросы, которые хотят ограничить выполненный объем работы, могут установить таймер, который вызовет sqlite3_interrupt(), если pragma продолжится слишком долго. Или, начиная с SQLite 3.32.0, применение может использовать PRAGMA analysis_limit=N для некоторого маленького значения N (несколько сотен или тысяч), чтобы ограничить глубину анализа.

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

Дополнительный аргумент MASK это битовая маска оптимизации:

Режим отладки. На самом деле не выполняет оптимизацию, но вместо этого возвращает строку текста для каждой оптимизации, которая была бы сделана. Off по умолчанию.
Выполните ANALYZE на таблицах, которые могли бы извлечь выгоду. По умолчанию On. Посмотрите ниже для получения дополнительной информации.
(Пока не реализовано) Информация об использовании и работе от текущей сессии в файле базы данных так, чтобы это было доступно "optimize" pragma, которым управляют будущие соединения с базой данных.
(Пока не реализовано) Создает индексы, которые, возможно, были полезны недавним запросам.

MASK по умолчанию всегда должен быть 0xfffe. 0xfffe выполняет всю оптимизацию, упомянутую выше, кроме Debug Mode. Если новая оптимизация будет добавлена в будущем, которая по умолчанию off, той новой оптимизации дадут маску 0x10000 или больше.

Чтобы видеть всю оптимизацию, которая обошлась бы без фактического ее выполнения, выполните "PRAGMA optimize(-1)". Чтобы использовать только оптимизацию ANALYZE, выполните "PRAGMA optimize(0x02)".

Определение того, когда выполнять анализ

В текущем внедрении таблица проанализирована если и только если все следующее верно:

Установлен MASK bit 0x02.
Планировщик запроса использовал статистику стиля sqlite_stat1 для одного или более индексов таблицы в какой-то момент в течение целой жизни текущей связи.
Один или более индексов таблицы в настоящее время не анализируются или количество строк в таблице увеличилось в 25 раз или больше с прошлого раза, когда выполняли ANALYZE.

Правила для того, когда таблицы будут проанализированы, вероятно, изменятся в будущих выпусках. PRAGMA page_count

PRAGMA schema.page_count;

Возвратите общее количество страниц в файле базы данных.

PRAGMA schema.page_size;
PRAGMA schema.page_size = bytes;

Запросите или задайте размер страницы базы данных. Размер страницы должен быть степенью двух между 512 и 65536 включительно.

Когда новая база данных создается, SQLite назначает размер страницы на базу данных на основе платформы и файловой системы. Много лет размер страницы по умолчанию был почти всегда 1024 байта, но начиная с SQLite version 3.12.0 (2016-03-29), размер страницы по умолчанию увеличен до 4096. Размер страницы по умолчанию рекомендуется для большинства приложений.

Определение нового размера страницы немедленно не изменяет размер страницы. Вместо этого новый размер страницы помнят и используют, чтобы установить размер страницы, когда база данных создается, если это еще не существует, когда выполнен page_size pragma, или в следующей команде VACUUM на том же самом соединении с базой данных не в режиме WAL.

Опция SQLITE_DEFAULT_PAGE_SIZE может использоваться, чтобы изменить размер страницы по умолчанию, назначенный на новые базы данных. PRAGMA parser_trace

PRAGMA parser_trace = boolean;

Если SQLite был собран с выбором времени компиляции SQLITE_DEBUG, то parser_trace pragma может использоваться, чтобы включить отслеживание для анализатора SQL, используемого внутренне SQLite. Эта функция используется для отладки самого SQLite.

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

PRAGMA pragma_list;

Этот pragma возвращает список команд PRAGMA, известных соединению с базой данных. PRAGMA query_only

PRAGMA query_only;
PRAGMA query_only = boolean;

query_only pragma предотвращает изменения данных в файлах базы данных, когда позволено. Когда этот pragma будет позволен, любая попытка CREATE, DELETE, DROP, INSERT или UPDATE приведет к ошибке SQLITE_READONLY. Однако, база данных не только для чтения. Можно все еще управлять checkpoint или COMMIT и возвращаемое значение sqlite3_db_readonly() не затронуто.

PRAGMA schema.quick_check;
PRAGMA schema.quick_check(N)
PRAGMA schema.quick_check(TABLENAME)

Это аналог integrity_check за исключением того, что это не проверяет ограничения UNIQUE и не проверяет, что содержание индекса соответствует содержанию таблицы. Пропуская UNIQUE и проверки на непротиворечивость индекса, quick_check в состоянии работать быстрее. PRAGMA quick_check требует O(N) времени, а PRAGMA integrity_check O(NlogN), где N это общее количество строк в базе данных. В остальном прагмы одинаковы.

PRAGMA read_uncommitted;
PRAGMA read_uncommitted = boolean;

Запросить, задать или очистить изоляцию READ UNCOMMITTED. Уровень изоляции по умолчанию для SQLite SERIALIZABLE. Любой процесс или поток могут выбрать изоляцию READ UNCOMMITTED, но SERIALIZABLE будет все еще использоваться кроме как между связями, которые поделятся общей страницей и кэшом схемы. Общий кэш позволен, используя sqlite3_enable_shared_cache() API, но по умолчанию выключен.

См. SQLite Shared-Cache Mode.

PRAGMA recursive_triggers;
PRAGMA recursive_triggers = boolean;

Запросить, задать или очистить рекурсивные триггеры.

Изменение урегулирования recursive_triggers затрагивает выполнение всех запросов, подготовленных, используя соединение с базой данных, включая подготовленные прежде, чем настройки были изменены. Любые существующие запросы, подготовленные с использованием sqlite3_prepare(), могут потерпеть неудачу с ошибкой SQLITE_SCHEMA после изменения recursive_triggers.

До SQLite version 3.6.18 (2009-09-11) не были поддержаны рекурсивные триггеры. Поведение SQLite всегда было таким, как будто этот pragma был установлен в OFF. Поддержка рекурсивных триггеров была добавлена в версии 3.6.18, но была первоначально выключена по умолчанию для совместимости. Рекурсивные триггеры могут быть включены по умолчанию в будущих версиях SQLite.

Глубине рекурсии для триггеров установили строгий верхний предел опцией компиляции SQLITE_MAX_TRIGGER_DEPTH и опцией выполнения sqlite3_limit(db, SQLITE_LIMIT_TRIGGER_DEPTH,...).

PRAGMA reverse_unordered_selects;
PRAGMA reverse_unordered_selects = boolean;

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

SQLite не делает гарантий о порядке результатов, если SELECT опускает пункт ORDER BY. Несмотря на это, порядок результатов не изменяется от одного запуска до следующего. Однако, иногда новые версии SQLite будут содержать улучшения оптимизатора, которые заставят порядок вывода запросов без пунктов ORDER BY меняться. Когда это происходит, запросы, которые зависят от определенного порядка вывода, могли бы работать со сбоями. Запуская приложение многократно с этим pragma, отключенным и позволенным, случаи, где применение делает дефектные предположения о порядке вывода, могут быть определены и решены, уменьшив проблемы, которые могли бы быть вызваны, связавшись с различной версией SQLite.

PRAGMA schema.schema_version;
PRAGMA schema.schema_version = integer ;

schema_version pragma получит или установит значение целого номера версии схемы в смещении 40 в заголовке базы данных.

SQLite автоматически увеличивает версию схемы каждый раз, когда схема изменяется. Когда каждый SQL-оператор работает, версия схемы проверяется, чтобы гарантировать, что схема не изменилась, с тех пор как SQL-оператор был подготовлен. Нарушение этого механизма при помощи "PRAGMA schema_version=N" может заставить SQL-оператор управлять использованием устаревшей схемы, которая может привести к неправильным ответам и/или повреждению БД. Всегда безопасно прочитать schema_version, но изменение schema_version может вызвать проблемы. Поэтому попытки изменить значение schema_version тихо игнорируются, когда включен defensive mode для соединения с базой данных.

Предупреждение: Неправильное употребление этого pragma может привести к повреждению БД.

В целях этого pragma команду VACUUM считают изменением схемы, так как VACUUM будет обычно изменять значения "rootpage" для записей в таблице sqlite_schema.

См. также application_id pragma and user_version pragma. PRAGMA secure_delete

PRAGMA schema.secure_delete;
PRAGMA schema.secure_delete = boolean|FAST

Запросите или измените secure-delete. Когда secure_delete = on, SQLite переписывает удаленное содержание нолями. Настройка по умолчанию для secure_delete определяется выбором времени компиляции SQLITE_SECURE_DELETE и обычно off. secure_delete = off улучшает работу, сокращая количество циклов CPU и сумму дискового I/O. Запросы, которые не хотят оставлять следы после содержания, должны позволить secure_delete pragma до выполнения удаления или обновления, или иначе управлять VACUUM после удаления или обновления.

Значение "fast" для secure_delete (добавлено 2017-08-01) является промежуточным звеном, устанавливающим промежуточный "on" и "off". Когда secure_delete будет установлен в "fast", SQLite перепишет удаленное содержание нолями, только если выполнение этого не увеличивает сумму I/O. Другими словами, "fast" использует больше циклов CPU, но не использует больше I/O. Это имеет эффект чистки всего старого содержания со страниц b-tree, но оставляет страницы freelist.

Когда есть приложенные базы данных, и никакая база данных не определяется в pragma, у всех баз данных есть своя настройка secure-delete. Значение secure-delete для недавно подключенных баз данных это урегулирование главной базы данных в то время, когда команда ATTACH оценена.

Когда многократные соединения с базой данных разделяют тот же самый кэш, изменение secure-delete на одном соединении с базой данных, изменяет его для всех.

Ограничения: secure_delete pragma только заставляет удаленное содержание вычищаться из обычных таблиц. Если виртуальные таблицы хранят содержание в теневых таблицах, удаление содержания из виртуальной таблицы не обязательно удаляет следы из теневых таблиц. В частности, FTS3 и FTS5, которые связаны с SQLite, могли бы оставить следы в их теневых таблицах, даже если secure_delete pragma позволен.

PRAGMA short_column_names;
PRAGMA short_column_names = boolean;

Запросите или измените флаг коротких имен столбцов. Этот флаг затрагивает режим, которым SQLite называет колонки данных, возвращенные SELECT. См. full_column_names.

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

PRAGMA shrink_memory

Этот pragma предписывает соединению с базой данных, на котором он вызван, освободить столько памяти, сколько можно, вызывая sqlite3_db_release_memory().

PRAGMA soft_heap_limit
PRAGMA soft_heap_limit=N

Этот pragma вызовает sqlite3_soft_heap_limit64() с параметром N, если N определяется и является неотрицательным целым числом. soft_heap_limit pragma всегда возвращает то же самое целое число, которое было бы возвращено sqlite3_soft_heap_limit64(-1).

См. также hard_heap_limit pragma. PRAGMA stats

PRAGMA stats;

Этот pragma возвращает вспомогательную информацию о таблицах и индексах. Возвращенная информация используется во время тестирования, чтобы помочь проверить, что планировщик запроса действует правильно. Формат и значение этого pragma, вероятно, изменятся от одного выпуска до следующего. Из-за его изменчивости поведение и выходной формат этого pragma сознательно не документированы.

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

PRAGMA schema.synchronous;
PRAGMA schema.synchronous = 0 | OFF | 1 | NORMAL | 2 | FULL | 3 | EXTRA;

Запросите или измените настройки "synchronous". Первая форма (запрос) возвратит значение как целое число. Вторая форма изменяет настройки. Значения различных синхронных параметров настройки следующие:

EXTRA (3): EXTRA похож на FULL с дополнением, что каталог, содержащий журнал обратной перемотки, синхронизируется после того, как тот журнал отключается, чтобы передать транзакцию в режиме DELETE. EXTRA обеспечивает дополнительную длительность, если передача сопровождается потерями мощности.
FULL (2): Когда synchronous = FULL (2), SQLite будет использовать метод xSync в VFS, чтобы гарантировать, что все содержание безопасно написано на диск до продолжения. Это гарантирует, что катастрофа операционной системы или перебой в питании не испортят базу данных. Синхронный FULL очень безопасен, но это также медленнее. FULL обычно используемое синхронное урегулирование если не в режиме WAL.
NORMAL (1): Когда synchronous = NORMAL (1), SQLite будет все еще синхронизировать в самые критические моменты, но менее часто, чем в режиме FULL. Есть очень маленький (хотя отличный от нуля) шанс, что перебой в питании в неправильное время мог испортить базу данных в journal_mode=DELETE в старой файловой системе. Режим WAL безопасен от повреждениц с synchronous=NORMAL и вероятно режим DELETE безопасен также в современных файловых системах. Режим WAL всегда согласовывается с synchronous=NORMAL, но режим WAL действительно теряет длительность. Транзакция, переданная в режиме WAL с synchronous=NORMAL, могла бы откатиться назад после системной катастрофы или потерь питания. Транзакции длительны через сбои приложения независимо от синхронного урегулирования или режима журнала. Урегулирование synchronous=NORMAL это хороший выбор для большинства ситуаций в режиме WAL.
OFF (0): С synchronous = OFF (0) SQLite работает не синхронизируя, как только это передало данные к операционной системе. Если приложение упадет, данные будут в безопасности, но БД может быть повреждена, если система навернется прежде чем те данные были написаны на диск. С другой стороны, передачи могут быть на порядки быстрее с synchronous = OFF.

В режиме WAL synchronous = NORMAL (1), файл WAL синхронизирован перед каждой checkpoint, файл базы данных синхронизирован после каждой законченной checkpoint, а заголовок файла WAL синхронизирован, когда файл WAL начинает снова использоваться после контрольной точки, но никакие синхронизирующие операции не происходят во время большинства транзакций. С synchronous=FULL в режиме WAL происходит дополнительная синхронизирующая операция файла WAL после каждой передачи транзакции. Дополнительная синхронизация WAL после каждой транзакции помогает гарантировать, что транзакции длительны через потери питания. Транзакции согласовываются с или без дополнительных синхронизаций, обеспеченных synchronous=FULL. Если длительность не беспокоит, synchronous=NORMAL обычно все, что надо в режиме WAL.

Схема TEMP всегда synchronous=OFF, так как содержание TEMP эфемерно и, как ожидают, не переживет отключение электроэнергии. Попытки изменить синхронные настройки для TEMP тихо проигнорированы.

См. также fullfsync and checkpoint_fullfsync pragma.

PRAGMA schema.table_info(table-name);

Этот pragma возвращает одну строку для каждой нормальной колонки в названной таблице. Колонки в наборе результатов включают: "name" (ее имя), "type" (тип данных, если дали, иначе ''), "notnull" (может ли столбец быть NULL), "dflt_value" (значение по умолчанию для колонки) и "pk" (ноль для колонок, которые не являются частью первичного ключа или индекс на основе 1 колонки в первичном ключе).

Столбец "cid" не должен быть взят, чтобы означать больше, чем "разряд в текущем наборе результатов".

Таблица, названная в table_info pragma, может также быть представлением.

Этот pragma не показывает информацию о произведенных или скрытых столбцах. Используйте PRAGMA table_xinfo, чтобы получить более полный список колонок, который включает произведенные и скрытые столбцы. PRAGMA table_list

PRAGMA table_list;
PRAGMA schema.table_list;
PRAGMA table_list(table-name);

Этот pragma возвращает информацию о таблицах и обзорах в схеме, одной таблице на строку вывода. table_list pragma сначала появился в версии SQLite version 3.37.0 (2021-11-27). С его первоначальной версии колонки, возвращенные table_list pragma, включают упомянутые ниже. Будущие версии SQLite, вероятно, добавят дополнительные колонки вывода.

schema: схема, в которой таблица или представление находятся (например, "main" или "temp").
name: название таблицы или представления.
type: тип объекта: один из "table", "view", "shadow" (для теневых таблиц) или "virtual" для виртуальных таблиц.
ncol: количество колонок в таблице, включая порожденные и теневые.
wr: 1, если таблица WITHOUT ROWID или 0, если нет.
strict: 1, если таблица STRICT или 0, если нет.
Дополнительные колонки будут, вероятно, добавлены в будущих выпусках.

Поведение по умолчанию должно показать все таблицы во всех схемах. Если имя schema. появляется перед pragma, тогда показывают таблицы только в той одной схеме. Если аргумент table-name поставляется, то возвращена только информация о той таблице. PRAGMA table_xinfo

PRAGMA schema.table_xinfo(table-name );

Этот pragma возвращает одну строку для каждой колонки в названной таблице, включая созданные и теневые. У вывода есть те же самые колонки, как у PRAGMA table_info плюс колонка "hidden", чье значение показывает нормальную колонку (0), динамическое или хранимую созданную (2 или 3) или скрытый столбец в виртуальной таблице (1). Строки, для которых эта область отличная от нуля, опущены в PRAGMA table_info. PRAGMA temp_store

Запросите или измените настройки "temp_store". Когда temp_store = DEFAULT (0), макрос C-препроцессора времени сборки SQLITE_TEMP_STORE используется, чтобы определить, где временные таблицы и индексы сохранены. Когда temp_store = MEMORY (2) временные таблицы и индексы сохранены, как будто они были в чистых БД в памяти. Когда temp_store = FILE (1) временные таблицы и индексы сохранены в файле. temp_store_directory pragma может использоваться, чтобы определить каталог, содержащий временные файлы, когда FILE определяется. Когда настройки temp_store изменяются, все существующие временные таблицы, индексы, триггеры и обзоры немедленно удалены.

В течение времени компиляции библиотеки C символ препроцессора SQLITE_TEMP_STORE возможно отвергнуть. Следующая таблица суммирует взаимодействие макроса препроцессора SQLITE_TEMP_STORE с temp_store pragma:

SQLITE_TEMP_STORE PRAGMA
temp_store
Таблицы TEMP и индексы хранить в

0 any файле

1 0 файле

1 1 файле

1 2 памяти

2 0 памяти

2 1 файле

2 2 памяти

3 any памяти

PRAGMA temp_store_directory;
PRAGMA temp_store_directory = 'directory-name';

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

При изменении temp_store_directory все существующие временные таблицы, индексы, триггеры и обзоры в соединении с базой данных, которая применила pragma, немедленно удалены. На практике temp_store_directory должен быть немедленно установлен после того, как первое соединение с базой данных для процесса открыто. Если temp_store_directory изменяется для одного соединения с базой данных, в то время как другие соединения с базой данных открыты в том же самом процессе, то поведение не определено и вероятно нежелательно.

Изменение настроек temp_store_directory не ориентировано на многопотоковое исполнение. Никогда не изменяйте настройки temp_store_directory, если другой поток в применении управляет каким-либо интерфейсом SQLite в то же время. Выполнение этого приводит к неопределенному поведению. Изменение настроек temp_store_directory пишет глобальную переменную sqlite3_temp_directory, а она не защищена mutex.

Значение directory-name должно быть приложено в одинарных кавычках. Чтобы вернуть каталог к умолчанию, установите directory-name в пустую строку, например, PRAGMA temp_store_directory = ''. Ошибка поднята, если directory-name не найдено или не перезаписываемо.

Каталог по умолчанию для временных файлов зависит от OS. Некоторые интерфейсы OS могут проигнорировать эту переменную и помещают временные файлы в некоторый другой каталог, отличающийся от каталога, определенного здесь. В этом смысле этот pragma только консультативный.

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

PRAGMA threads;
PRAGMA threads = N;

Запросите или измените значение предела sqlite3_limit(db, SQLITE_LIMIT_WORKER_THREADS,...) для текущего соединения с базой данных. Этот предел устанавливает верхнюю границу количества вспомогательных потоков, которые подготовленному запросу позволяют начать, чтобы помочь с запросом. Предел по умолчанию 0, если он не изменяется, используя выбор времени компиляции SQLITE_DEFAULT_WORKER_THREADS. Когда предел ноль, это означает, что никакие вспомогательные потоки не будут начаты.

Этот pragma просто обертка вокруг sqlite3_limit(db, SQLITE_LIMIT_WORKER_THREADS,...).

PRAGMA trusted_schema;
PRAGMA trusted_schema = boolean;

Урегулирование trusted_schema boolean для каждого подключения, которое определяет, функционирует ли SQL и виртуальные таблицы, которые не были проверены на безопасность, работать в обзорах, триггерах или выражениях схемы, таких как ограничения CHECK, выражение DEFAULT, произведенных колонках, индексах выражения и/или частичных индексах. Этим урегулированием можно также управлять, используя sqlite3_db_config(db, SQLITE_DBCONFIG_TRUSTED_SCHEMA,...).

Чтобы поддержать совместимость, это урегулирование по умолчанию ON. Есть преимущества для его выключения, и большинство запросов не будет затронуто, если это будет выключено. По этой причине все запросы поощряются выключить это урегулирование на каждом соединении с базой данных, как только та связь открыта.

Выбор времени компиляции -DSQLITE_TRUSTED_SCHEMA=0 заставит это урегулирование по умолчанию быть OFF. PRAGMA user_version

PRAGMA schema.user_version;
PRAGMA schema.user_version = integer ;

user_version pragma получит или установит значение целого числа пользовательской версии в смещении 60 в заголовке базы данных. Пользовательская версия это целое число, которое доступно приложениям. SQLite не использует его сам.

См. также application_id pragma и schema_version pragma. PRAGMA vdbe_addoptrace

PRAGMA vdbe_addoptrace = boolean;

Если SQLite был собран с выбором времени компиляции SQLITE_DEBUG, vdbe_addoptrace pragma может использоваться, чтобы заставить полные коды операции VDBE быть показанными, когда они создаются во время генерации кода. Эта функция используется для отладки самого SQLite. См. здесь.

PRAGMA vdbe_debug = boolean;

Если SQLite был собран с выбором времени компиляции SQLITE_DEBUG, vdbe_debug pragma является сокращением для трех других pragma только для отладки: vdbe_addoptrace, vdbe_listing и vdbe_trace. Эта функция используется для отладки самого SQLite. См. здесь.

PRAGMA vdbe_listing = boolean;

Если SQLite был собран с выбором времени компиляции SQLITE_DEBUG, vdbe_listing pragma может использоваться, чтобы заставить полный список кодов операции виртуальной машины появляться на стандартном выводе, когда каждый запрос оценен. С листингом все содержание программы печатается только до выполнения. Запрос обычно выполняется после того, как листинг печатается. Эта функция используется для отладки самого SQLite. См. VDBE.

PRAGMA vdbe_trace = boolean;

Если SQLite был собран с выбором времени компиляции SQLITE_DEBUG, vdbe_trace pragma может использоваться, чтобы заставить коды операции виртуальной машины быть напечатанными на стандартном выводе, когда они оценены. Эта функция используется для отладки SQLite. См. VDBE.

PRAGMA wal_autocheckpoint;
PRAGMA wal_autocheckpoint=N;

Этот pragma запрашивает или устанавливает интервал auto-checkpoint для журнала с упреждающей записью Когда журнал с упреждающей записью включен (через journal_mode pragma), контрольной точкой будут управлять автоматически каждый раз, когда журнал с упреждающей записью равняется или превышает N страниц в длину. Урегулирование размера автоконтрольной точки к нолю или отрицательной величине выключает auto-checkpointing.

Этот pragma обертка вокруг sqlite3_wal_autocheckpoint(). Все автоматические контрольные точки PASSIVE.

Autocheckpointing позволяют по умолчанию с интервалом 1000 или SQLITE_DEFAULT_WAL_AUTOCHECKPOINT.

PRAGMA schema.wal_checkpoint;
PRAGMA schema.wal_checkpoint(PASSIVE);
PRAGMA schema.wal_checkpoint(FULL);
PRAGMA schema.wal_checkpoint(RESTART);
PRAGMA schema.wal_checkpoint(TRUNCATE);

Если включен журнал с упреждающей записью (через journal_mode pragma), этот pragma заставляет операцию checkpoint работать на базе данных database или на всех приложенных базах данных, если database не указана. Если журнал с упреждающей записью выключен, этот pragma безопасно ничего не делает.

Вызов этого pragma без аргумента эквивалентен запросу sqlite3_wal_checkpoint(). Вызов этого pragma с аргументом эквивалентен запросу sqlite3_wal_checkpoint_v2() с 3-м параметром, соответствующим аргументу:

PASSIVE: Контрольная точка обработает как можно больше структур, не ожидая завершения никаких читателей или писателей базы данных. Синхронизирует файл БД, если все структуры в журнале checkpointed. Этот режим совпадает с запросом sqlite3_wal_checkpoint(). Отзыв busy-handler никогда не вызывается в этом режиме.
FULL: Этот режим блокирует (вызовом busy-handler) пока нет никакого писателя базы данных, все читатели читает от нового образа базы данных. Это делает контрольные точки всех структур в файле журнала и синхронизирует файл базы данных. FULL блокирует параллельных писателей, в то время как он работает, но читатели могут продолжить работу.
RESTART: Этот режим работает как FULL с дополнением, что после checkpointing файла журнала это блокирует (вызывая busy-handler) пока все читатели не закончат работу с файлом журнала. Это гарантирует, что следующий клиент, который напишет файл базы данных, перезапускает файл журнала с начала. RESTART блокирует параллельных писателей, в то время как он работает, но читатели могут продолжить работу.
TRUNCATE: Этот режим работает как RESTART, но файл WAL усечен к нулю байт после успешного завершения.

wal_checkpoint pragma возвращает единственную строку с тремя колонками целого числа. Первая колонка обычно 0, но будет 1, если контрольная точка RESTART, FULL или TRUNCATE были заблокированы на завершении, например потому что другой поток или процесс активно использовали базу данных. Другими словами, первая колонка 0, если бы эквивалентный вызов sqlite3_wal_checkpoint_v2() возвратил бы SQLITE_OK, или 1, если бы эквивалентный вызов возвратил бы SQLITE_BUSY. Вторая колонка это число измененных страниц, которые были написаны в файл журнала с упреждающей записью. Третья колонка это число страниц в файле журнала с упреждающей записью, которые успешно перемещены в файл базы данных в конце контрольной точки. Вторая и третья колонка -1, если нет никакого журнала с упреждающей записью, например если этот pragma вызван на соединении с базой данных, которое не находится в режиме WAL.

PRAGMA writable_schema = boolean;
PRAGMA writable_schema = RESET

Когда этот pragma on и флаг SQLITE_DBCONFIG_DEFENSIVE = off, таблица sqlite_schema может быть изменена, используя обычный UPDATE, INSERT или DELETE. Если параметр "RESET", написание схемы отключено (как с "PRAGMA writable_schema=OFF") и, кроме того, схема перезагружается. Предупреждение: неправильное употребление этого pragma может легко привести к повреждению БД.