The PRAGMA command is a special command used to modify the operation of the SQLite library or to query the library for internal (non-table) data. The PRAGMA command is issued using the same interface as other SQLite commands (e.g. SELECT, INSERT) but is different different in the following important respects:

• Specific pragma statements may be removed and others added in future releases of SQLite. Use with caution!
• No error messages are generated if an unknown pragma is issued. Unknown pragmas are simply ignored. This means if there is a typo in a pragma statement the library does not inform the user of the fact.
• Some pragmas take effect during the SQL compilation stage, not the execution stage. This means if using the C-language sqlite3_compile(), sqlite3_step(), sqlite3_finalize() API (or similar in a wrapper interface), the pragma may be applied to the library during the sqlite3_compile() call.
• The pragma command is unlikely to be compatible with any other SQL engine.

The available pragmas fall into four basic categories:

• Pragmas used to query the schema of the current database.
• Pragmas used to modify the operation of the SQLite library in some manner, or to query for the current mode of operation.
• Pragmas used to query or modify the databases two cookie values, the schema-cookie and the user-cookie.
• Pragmas used to debug the library and verify that database files are not corrupted.

PRAGMA command syntax

The pragmas that take an integer value also accept symbolic names. The strings "on", "true", and "yes" are equivalent to 1. The strings "off", "false", and "no" are equivalent to 0. These strings are case- insensitive, and do not require quotes. An unrecognized string will be treated as 1, and will not generate an error. When the value is returned it is as an integer.

Pragmas to modify library operation

• PRAGMA auto_vacuum;
  PRAGMA auto_vacuum = 0 | 1;

  Query or set the auto-vacuum flag in the database.

  Normally, when a transaction that deletes data from a database is committed, the database file remains the same size. Unused database file pages are marked as such and reused later on, when data is inserted into the database. In this mode the VACUUM command is used to reclaim unused space.

  When the auto-vacuum flag is set, the database file shrinks when a transaction that deletes data is committed (The VACUUM command is not useful in a database with the auto-vacuum flag set). To support this functionality the database stores extra information internally, resulting in slightly larger database files than would otherwise be possible.

  It is only possible to modify the value of the auto-vacuum flag before any tables have been created in the database. No error message is returned if an attempt to modify the auto-vacuum flag is made after one or more tables have been created.

• PRAGMA cache_size;
  PRAGMA cache_size = Number-of-pages;

  Query or change the maximum number of database disk pages that SQLite will hold in memory at once. Each page uses about 1.5K of memory. The default cache size is 2000. If you are doing UPDATEs or DELETEs that change many rows of a database and you do not mind if SQLite uses more memory, you can increase the cache size for a possible speed improvement.

  When you change the cache size using the cache_size pragma, the change only endures for the current session. The cache size reverts to the default value when the database is closed and reopened. Use the default_cache_size pragma to check the cache size permanently.

• PRAGMA default_cache_size;
  PRAGMA default_cache_size = Number-of-pages;

  Query or change the maximum number of database disk pages that SQLite will hold in memory at once. Each page uses 1K on disk and about 1.5K in memory. This pragma works like the cache_size pragma with the additional feature that it changes the cache size persistently. With this pragma, you can set the cache size once and that setting is retained and reused every time you reopen the database.

• PRAGMA default_synchronous;
  PRAGMA default_synchronous = FULL; (2)
  PRAGMA default_synchronous = NORMAL; (1)
  PRAGMA default_synchronous = OFF; (0)

  Query or change the setting of the "synchronous" flag in the database. The first (query) form will return the setting as an integer. When synchronous is FULL (2), the SQLite database engine will pause at critical moments to make sure that data has actually been written to the disk surface before continuing. This ensures that if the operating system crashes or if there is a power failure, the database will be uncorrupted after rebooting. FULL synchronous is very safe, but it is also slow. When synchronous is NORMAL (1, the default), the SQLite database engine will still pause at the most critical moments, but less often than in FULL mode. There is a very small (though non-zero) chance that a power failure at just the wrong time could corrupt the database in NORMAL mode. But in practice, you are more likely to suffer a catastrophic disk failure or some other unrecoverable hardware fault. So NORMAL is the default mode. With synchronous OFF (0), SQLite continues without pausing as soon as it has handed data off to the operating system. If the application running SQLite crashes, the data will be safe, but the database might become corrupted if the operating system crashes or the computer loses power before that data has been written to the disk surface. On the other hand, some operations are as much as 50 or more times faster with synchronous OFF.

  This pragma changes the synchronous mode persistently. Once changed, the mode stays as set even if the database is closed and reopened. The synchronous pragma does the same thing but only applies the setting to the current session.

• PRAGMA default_temp_store;
  PRAGMA default_temp_store = DEFAULT; (0)
  PRAGMA default_temp_store = MEMORY; (2)
  PRAGMA default_temp_store = FILE; (1)

  Query or change the setting of the "temp_store" flag stored in the database. When temp_store is DEFAULT (0), the compile-time value of the symbol TEMP_STORE is used for the temporary database. When temp_store is MEMORY (2), an in-memory database is used. When temp_store is FILE (1), a temporary database file on disk will be used. It is possible for the library compile-time symbol TEMP_STORE to override this setting. The following table summarizes this:

  TEMP_STORE	temp_store	temp database location
  0	any	file
  1	0	file
  1	1	file
  1	2	memory
  2	0	memory
  2	1	file
  2	2	memory
  3	any	memory

  This pragma changes the temp_store mode for whenever the database is opened in the future. The temp_store mode for the current session is unchanged. Use the temp_store pragma to change the temp_store mode for the current session.

• PRAGMA synchronous;
  PRAGMA synchronous = FULL; (2)
  PRAGMA synchronous = NORMAL; (1)
  PRAGMA synchronous = OFF; (0)

  Query or change the setting of the "synchronous" flag affecting the database for the duration of the current database connection. The synchronous flag reverts to its default value when the database is closed and reopened. For additional information on the synchronous flag, see the description of the default_synchronous pragma.

• PRAGMA temp_store;
  PRAGMA temp_store = DEFAULT; (0)
  PRAGMA temp_store = MEMORY; (2)
  PRAGMA temp_store = FILE; (1)

  Query or change the setting of the "temp_store" flag affecting the database for the duration of the current database connection. The temp_store flag reverts to its default value when the database is closed and reopened. For additional information on the temp_store flag, see the description of the default_temp_store pragma. Note that it is possible for the library compile-time options to override this setting.

  When the temp_store setting is changed, all existing temporary tables, indices, triggers, and viewers are immediately deleted.

Pragmas to query the database schema

• PRAGMA database_list;

  For each open database, invoke the callback function once with information about that database. Arguments include the index and the name the database was attached with. The first row will be for the main database. The second row will be for the database used to store temporary tables.

• PRAGMA foreign_key_list(table-name);

  For each foreign key that references a column in the argument table, invoke the callback function with information about that foreign key. The callback function will be invoked once for each column in each foreign key.

• PRAGMA index_info(index-name);

  For each column that the named index references, invoke the callback function once with information about that column, including the column name, and the column number.

• PRAGMA index_list(table-name);

  For each index on the named table, invoke the callback function once with information about that index. Arguments include the index name and a flag to indicate whether or not the index must be unique.

• PRAGMA table_info(table-name);

  For each column in the named table, invoke the callback function once with information about that column, including the column name, data type, whether or not the column can be NULL, and the default value for the column.

Pragmas to query/modify cookie values

• PRAGMA [database.]schema_cookie;
  PRAGMA [database.]schema_cookie = integer ;
  PRAGMA [database.]user_cookie;
  PRAGMA [database.]user_cookie = integer ;

  The pragmas schema_cookie and user_cookie are used to set or get the value of the schema-cookie and user-cookie, respectively. Both the schema-cookie and the user-cookie are 32-bit signed integers stored in the database header.

  The schema-cookie is usually only manipulated internally by SQLite. It is incremented by SQLite whenever the database schema is modified (by creating or dropping a table or index). The schema cookie is used by SQLite each time a query is executed to ensure that the internal cache of the schema used when compiling the SQL query matches the schema of the database against which the compiled query is actually executed. Subverting this mechanism by using "PRAGMA schema_cookie" to modify the schema-cookie is potentially dangerous and may lead to program crashes or database corruption. Use with caution!

  The user-cookie is not used internally by SQLite. It may be used by applications for any purpose.

Pragmas to debug the library

• PRAGMA integrity_check;

  The command does an integrity check of the entire database. It looks for out-of-order records, missing pages, malformed records, and corrupt indices. If any problems are found, then a single string is returned which is a description of all problems. If everything is in order, "ok" is returned.

• PRAGMA parser_trace = ON; (1)
  PRAGMA parser_trace = OFF; (0)

  Turn tracing of the SQL parser inside of the SQLite library on and off. This is used for debugging. This only works if the library is compiled without the NDEBUG macro.

• PRAGMA vdbe_trace = ON; (1)
  PRAGMA vdbe_trace = OFF; (0)

  Turn tracing of the virtual database engine inside of the SQLite library on and off. This is used for debugging. See the VDBE documentation for more information.