^(PRAGMA count_changes; +
PRAGMA count_changes;
PRAGMA count_changes = boolean;
Query or change the count-changes flag.)^ ^Normally, when the +
Query or change the count-changes flag. Normally, when the count-changes flag is not set, [INSERT], [UPDATE] and [DELETE] statements - return no data. ^When count-changes is set, each of these commands + return no data. When count-changes is set, each of these commands returns a single row of data consisting of one integer value - the - number of rows inserted, modified or deleted by the command. ^The + number of rows inserted, modified or deleted by the command. The returned change count does not include any insertions, modifications or deletions performed by triggers, or any changes made automatically by [foreign key actions].
Another way to get the row change counts is to use the [sqlite3_changes()] or [sqlite3_total_changes()] interfaces. - There is a subtle different, though. ^When an INSERT, UPDATE, or + There is a subtle different, though. When an INSERT, UPDATE, or DELETE is run against a view using an [INSTEAD OF trigger], the count_changes pragma reports the number of rows in the view that fired the trigger, whereas [sqlite3_changes()] and [sqlite3_total_changes()] do not. } @@ -343,19 +343,19 @@ and not depend on the default setting. } LegacyPragma full_column_names { -
^(PRAGMA full_column_names; +
PRAGMA full_column_names;
PRAGMA full_column_names = boolean;
Query or change the full_column_names flag.)^ ^This flag together +
Query or change the full_column_names flag. This flag together with the [short_column_names] flag determine the way SQLite assigns names to result columns of [SELECT] statements. - ^(Result columns are named by applying the following rules in order: + Result columns are named by applying the following rules in order:
If there is an AS clause on the result, then the name of the column is the right-hand side of the AS clause.
If the result is a general expression, not a just the name of a source table column, @@ -366,11 +366,11 @@
If both pragmas [short_column_names] and [full_column_names] are OFF then case (2) applies.
The name of the result column is a combination of the source table and source column name: TABLE.COLUMN
^(PRAGMA fullfsync
PRAGMA fullfsync = boolean;
See also [checkpoint_fullfsync].
} Pragma incremental_vacuum { -PRAGMA incremental_vacuum(N);
-^The incremental_vacuum pragma causes up to N pages to - be removed from the [freelist]. ^The database file is truncated by + ^(
PRAGMA incremental_vacuum(N);
+The incremental_vacuum pragma causes up to N pages to + be removed from the [freelist].)^ ^The database file is truncated by the same amount. ^The incremental_vacuum pragma has no effect if the database is not in auto_vacuum=incremental mode or if there are no pages on the freelist. ^If there are fewer than N pages on the freelist, or if N is less than 1, or @@ -726,16 +726,16 @@ all.
} LegacyPragma short_column_names { -^(PRAGMA short_column_names; +
PRAGMA short_column_names;
PRAGMA short_column_names = boolean;
Query or change the short-column-names flag.)^ ^This flag affects +
Query or change the short-column-names flag. This flag affects the way SQLite names columns of data returned by [SELECT] statements. See the [full_column_names] pragma for full details.
} @@ -837,19 +837,19 @@ )^ } LegacyPragma temp_store_directory { -^(PRAGMA temp_store_directory; +
PRAGMA temp_store_directory;
PRAGMA temp_store_directory = 'directory-name';
Query or change the value of the [sqlite3_temp_directory] global variable, which many operating-system interface backends use to - determine where to store [temporary tables] and indices.
)^ + determine where to store [temporary tables] and indices. DISCLAIMER -^When the temp_store_directory setting is changed, all existing temporary +
When the temp_store_directory setting is changed, all existing temporary tables, indices, triggers, and viewers in the database connection that issued the pragma are immediately deleted. In practice, temp_store_directory should be set immediately after the first database connection for a process is opened. If the temp_store_directory is changed for one database connection while other database connections @@ -857,17 +857,17 @@ probably undesirable.
Changing the temp_store_directory setting is not threadsafe. Never change the temp_store_directory setting if another thread within the application is running any SQLite interface at the same time. - Doing so results in undefined behavior. ^Changing the temp_store_directory + Doing so results in undefined behavior. Changing the temp_store_directory setting writes to the [sqlite3_temp_directory] global variable and that global variable is not protected by a mutex.
The value directory-name should be enclosed in single quotes. - ^(To revert the directory to the default, set the directory-name to - an empty string, e.g., PRAGMA temp_store_directory = ''.)^ ^An + To revert the directory to the default, set the directory-name to + an empty string, e.g., PRAGMA temp_store_directory = ''. An error is raised if directory-name is not found or is not writable.
The default directory for temporary files depends on the OS. Some OS interfaces may choose to ignore this variable and place temporary @@ -899,14 +899,11 @@ a column in the argument table.)^ } Pragma freelist_count {
^(PRAGMA freelist_count;
-Return the number of unused pages in the database file.)^ ^Running - a "PRAGMA incremental_vaccum(N);" - command with a large value of N will shrink the database file by this - number of pages when incremental vacuum is enabled.
+Return the number of unused pages in the database file.)^
} Pragma index_info {^(PRAGMA index_info(index-name);
This pragma returns one row each column in the named index.)^ @@ -1054,19 +1051,23 @@ Pragma wal_autocheckpoint {
PRAGMA wal_autocheckpoint;
PRAGMA wal_autocheckpoint=N;
^This pragma queries or sets the [write-ahead log] auto-checkpoint - interval. When the [write-ahead log] is enabled (via the +
^This pragma queries or sets the [write-ahead log] + [checkpointing | auto-checkpoint] interval. + When the [write-ahead log] is enabled (via the [journal_mode pragma]) a checkpoint will be run automatically whenever the write-ahead log equals or exceeds N pages in length. Setting the auto-checkpoint size to zero or a negative value turns auto-checkpointing off.
^This pragma is a wrapper around the [sqlite3_wal_autocheckpoint()] C interface.
+ +^Autocheckpointing is enabled by default with an interval + of 1000 or [SQLITE_DEFAULT_WAL_AUTOCHECKPOINT].
} Pragma ignore_check_constraints {^(PRAGMA ignore_check_constraints = boolean;
Index: pages/wal.in ================================================================== --- pages/wal.in +++ pages/wal.in @@ -97,11 +97,13 @@ whereas with a write-ahead log there are now three primitive operations: reading, writing, and checkpointing.By default, SQLite does a checkpoint automatically when the WAL file -reaches a threshold size of 1000 pages. Applications using WAL do +reaches a threshold size of 1000 pages. (The +[SQLITE_DEFAULT_WAL_AUTOCHECKPOINT] compile-time option can be used to +specify a different default.) Applications using WAL do not have to do anything in order to for these checkpoints to occur. But if they want to, applications can adjust the automatic checkpoint threshold. Or they can turn off the automatic checkpoints and run checkpoints during idle moments or in a separate thread or process.