(docsrc) pages/compile.in changes.
(1) By brickviking on 2025-05-18 10:40:02 [source]
There are quite a few changes in this file, so I decided to bundle them all up:
Index: pages/compile.in
==================================================================
--- pages/compile.in
+++ pages/compile.in
@@ -321,5 +321,5 @@
[foreign key constraints] is enabled or disabled by default for
new database connections. Each database connection can always turn
- enforcement of foreign key constraints on and off and run-time using
+ enforcement of foreign key constraints on and off at run-time using
the [foreign_keys pragma]. Enforcement of foreign key constraints
is normally off by default, but if this compile-time parameter is
@@ -330,5 +330,5 @@
This macro sets the default limit on the amount of memory that
will be used for memory-mapped I/O
- for each open database file. If the <i>N</i>
+ for each open database file. If <i>N</i>
is zero, then memory mapped I/O is disabled by default. This
compile-time limit and the [SQLITE_MAX_MMAP_SIZE] can be modified
@@ -420,9 +420,7 @@
COMPILE_OPTION {SQLITE_DEFAULT_WORKER_THREADS=<i>N</i>} {
- This macro sets the default value for
- the [SQLITE_LIMIT_WORKER_THREADS] parameter. The [SQLITE_LIMIT_WORKER_THREADS]
- parameter sets the maximum number of auxiliary threads that a single
- [prepared statement] will launch to assist it with a query. If not specified,
- the default maximum is 0.
+ This macro sets the default value for the maximum number of auxiliary
+ threads that a single [prepared statement] will launch to assist it with a
+ query. If not specified, the default maximum is 0.
The value set here cannot be more than [SQLITE_MAX_WORKER_THREADS].
}
@@ -534,5 +532,5 @@
build. This option does change the default memory-mapped I/O address
space size (set by [SQLITE_DEFAULT_MMAP_SIZE] or
- sqlite3_config([SQLITE_CONFIG_MMAP_SIZE]) or the
+ sqlite3_config([SQLITE_CONFIG_MMAP_SIZE])) or the
run-time memory-mapped I/O address space size (set by
sqlite3_file_control([SQLITE_FCNTL_MMAP_SIZE]) or
@@ -653,5 +651,5 @@
The [SQLITE_QUERY_PLANNER_LIMIT] option sets an initial baseline value
for the maximum number of index-and-constraint combinations that the
- query planner consider. The baseline query planner limit is increased
+ query planner considers. The baseline query planner limit is increased
by SQLITE_QUERY_PLANNER_LIMIT_INCR prior to processing each table of a
join so that each table is guaranteed to be able to propose at least
@@ -893,5 +891,5 @@
COMPILE_OPTION {SQLITE_TRACE_SIZE_LIMIT=<i>N</i>} {
If this macro is defined to a positive integer <i>N</i>, then the length of
- strings and BLOB that are expanded into parameters in the output of
+ strings and BLOBs that are expanded into parameters in the output of
[sqlite3_trace()] is limited to <i>N</i> bytes.
}
@@ -928,4 +926,5 @@
by default.
}
+
COMPILE_OPTION {SQLITE_ALLOW_COVERING_INDEX_SCAN=<i><0 or 1></i>} {
This C-preprocess macro determines the default setting of the
@@ -936,5 +935,5 @@
to appear in a different order from legacy, which could cause some
(incorrectly-coded) legacy applications to break. Hence, the covering
- index scan option can be disabled at compile-time on systems that what
+ index scan option can be disabled at compile-time on systems that want
to minimize their risk of exposing errors in legacy applications.
}
@@ -943,5 +942,5 @@
If this C-preprocessor macro is defined, then extra code is
included that allows SQLite to function on a filesystem that
- only support 8+3 filenames. If the value of this macro is 1,
+ only supports 8+3 filenames. If the value of this macro is 1,
then the default behavior is to continue to use long filenames and
to only use 8+3 filenames if the
@@ -966,5 +965,5 @@
SQLITE_ENABLE_API_ARMOR compile-time option is intended as an aid
for application testing and debugging option. Applications
- should not depend SQLITE_ENABLE_API_ARMOR for safety.
+ should not depend on SQLITE_ENABLE_API_ARMOR for safety.
SQLITE_ENABLE_API_ARMOR is appropriate as a second line of
defense against application bugs, but it should not be the only
@@ -995,5 +994,5 @@
COMPILE_OPTION {SQLITE_ENABLE_BATCH_ATOMIC_WRITE} {
- This compile-time option enables SQLite to take advantage batch
+ This compile-time option enables SQLite to take advantage of batch
atomic write capabilities in the underlying filesystem. As of
SQLite version 3.21.0 ([dateof:3.21.0]) this is only supported on
@@ -1001,5 +1000,5 @@
is implemented generically, using [sqlite3_file_control()] with
[SQLITE_FCNTL_BEGIN_ATOMIC_WRITE] and [SQLITE_FCNTL_COMMIT_ATOMIC_WRITE]
- so the capability can be added to other filesystem times in the
+ so the capability can be added to other filesystems some time in the
future. When this option is enabled, SQLite automatically detects
that the underlying filesystem supports batch atomic writes, and
@@ -1053,5 +1052,5 @@
output of [EXPLAIN]. These extra comments use extra memory, thus
making [prepared statements] larger and very slightly slower, and so they are
- turned off by default and in most application. But some applications, such
+ turned off by default and in most applications. But some applications, such
as the [command-line shell] for SQLite, value clarity of EXPLAIN output
over raw performance and so this compile-time option is available to them.
@@ -1059,5 +1058,4 @@
automatically if [SQLITE_DEBUG] is enabled.
}
-
COMPILE_OPTION {SQLITE_ENABLE_FTS3} {
@@ -1069,5 +1067,5 @@
This option modifies the query pattern parser in FTS3 such that it
supports operators AND and NOT (in addition to the usual OR and NEAR)
- and also allows query expressions to contain nested parenthesis.
+ and also allows query expressions to contain nested parentheses.
}
@@ -1074,9 +1072,9 @@
COMPILE_OPTION {SQLITE_ENABLE_FTS3_TOKENIZER} {
This option enables the two-argument version of the [fts3_tokenizer()]
- interface. The second argument to fts3_tokenizer() is suppose to be a
+ interface. The second argument to fts3_tokenizer() should be a
pointer to a function (encoded as a BLOB) that implements an
application defined tokenizer. If hostile actors are able to run
the two-argument version of fts3_tokenizer() with an arbitrary second
- argument, they could use crash or take control of the process.
+ argument, they could use, crash or take control of the process.
<p>
Because of security concerns, the two-argument fts3_tokenizer() feature
@@ -1095,5 +1093,5 @@
COMPILE_OPTION {SQLITE_ENABLE_FTS5} {
- When this option is defined in the [amalgamation], versions 5
+ When this option is defined in the [amalgamation], version 5
of the full-text search engine ([fts5]) is added to the build automatically.
}
@@ -1116,5 +1114,5 @@
COMPILE_OPTION {SQLITE_ENABLE_IOTRACE} {
- When both the SQLite core and the [Command Line Interface] (CLI) are both
+ When both the SQLite core and the [Command Line Interface] (CLI) are
compiled with this option, then the CLI provides an extra command
named ".iotrace" that provides a low-level log of I/O activity.
@@ -1133,5 +1131,5 @@
This option enables additional logic in the OS interface layer for
Mac OS X. The additional logic attempts to determine the type of the
- underlying filesystem and choose and alternative locking strategy
+ underlying filesystem and choose an alternative locking strategy
that works correctly for that filesystem type. Five locking strategies
are available:
@@ -1152,5 +1150,5 @@
<li> Dot-file locking style. This locking style is used when neither
flock nor POSIX locking styles are supported by the file system.
- Database locks are obtained by creating and entry in the file-system
+ Database locks are obtained by creating an entry in the file-system
at a well-known location relative to the database file (a "dot-file")
and relinquished by deleting the same file.
@@ -1243,5 +1241,5 @@
<p><pre>
SELECT percentile_cont(0.75) WITHIN GROUP (ORDER BY x) FROM tab;</pre>
- <p>The above is the SQL-standard way to compute the 75-percentile
+ <p>The above is the SQL-standard way to compute the 75th-percentile
value of a distribution. The usual way to do this in SQLite is
as follows:
@@ -1294,5 +1292,5 @@
COMPILE_OPTION {SQLITE_ENABLE_RBU} {
- Enable the code the implements the [RBU extension].
+ Enable the code that implements the [RBU extension].
}
@@ -1354,5 +1352,5 @@
[sqlite3_stmt_scanstatus_v2()] interfaces. Those
interfaces are normally omitted from the build
- because they imposes a performance penalty, even on statements that
+ because they impose a performance penalty, even on statements that
do not use the feature.
}
@@ -1405,5 +1403,5 @@
COMPILE_OPTION {SQLITE_ENABLE_STAT4} {
This option adds additional logic to the [ANALYZE] command and to
- the [query planner] that can help SQLite to chose a better query plan
+ the [query planner] that can help SQLite to choose a better query plan
under certain situations. The [ANALYZE] command is enhanced to collect
histogram data from all columns of every index and store that data
@@ -1461,7 +1459,6 @@
COMPILE_OPTION {SQLITE_INTROSPECTION_PRAGMAS} {
- This option is obsolete. It used to enable some extra
- some extra PRAGMA statements such as
- [PRAGMA function_list], [PRAGMA module_list], and
+ This option is obsolete. It used to enable some extra PRAGMA statements
+ such as [PRAGMA function_list], [PRAGMA module_list], and
[PRAGMA pragma_list], but those pragmas are now all
enabled by default. See [SQLITE_OMIT_INTROSPECTION_PRAGMAS].
@@ -1475,5 +1472,5 @@
This option causes [application-defined SQL functions] to raise an SQL
error if they invoke the [sqlite3_result_subtype()] interface but
- where not registered with the [SQLITE_RESULT_SUBTYPE] property.
+ were not registered with the [SQLITE_RESULT_SUBTYPE] property.
This recommended option helps to identify problems in the
implementation of application-defined SQL functions early in the
@@ -1505,5 +1502,5 @@
<p>
This option has no effect on the SQLite core. It is only used by extensions.
- This is option is necessary for the compression and decompression
+ This option is necessary for the compression and decompression
functions that are part of [SQL Archive] support in the
[command-line shell].
@@ -1511,5 +1508,5 @@
When compiling with this option, it will normally
be necessary to add a linker option to include the zlib library in the
- build. Normal this option is "-lz" but might be different on different
+ build. Normally this option is "-lz" but might be different on different
systems.
<p>
@@ -1553,5 +1550,5 @@
COMPILE_OPTION {SQLITE_DISABLE_FTS4_DEFERRED} {
- If this C-preprocessor macro disables the "deferred token" optimization
+ This C-preprocessor macro disables the "deferred token" optimization
in [FTS4]. The "deferred token" optimization avoids loading massive
posting lists for terms that are in most documents of the collection
@@ -1567,5 +1564,5 @@
COMPILE_OPTION {SQLITE_DISABLE_PAGECACHE_OVERFLOW_STATS} {
- This option disables the collection of the [sqlite3_status()]
+ This option disables the collection of the [sqlite3_status()],
[SQLITE_STATUS_PAGECACHE_OVERFLOW] and [SQLITE_STATUS_PAGECACHE_SIZE]
statistics. Setting this option has been shown to increase performance in
@@ -1665,12 +1662,11 @@
COMPILE_OPTION {SQLITE_OMIT_AUTHORIZATION} {
- Defining this option omits the authorization callback feature from the
- library. The [sqlite3_set_authorizer()] API function is not present
- in the library.
+ Defining this option omits the [sqlite3_set_authorizer()] API
+ function from the library.
}
COMPILE_OPTION {SQLITE_OMIT_AUTOINCREMENT} {
- This option is omits the [AUTOINCREMENT] feature.
- When this is macro is defined, columns declared as
+ This option omits the [AUTOINCREMENT] feature when enabled.
+ When this macro is defined, columns declared as
"[INTEGER PRIMARY KEY] AUTOINCREMENT"
behave in the same way as columns declared as "[INTEGER PRIMARY KEY]" when a
@@ -1702,5 +1698,5 @@
[sqlite3_reset()] to reset the [prepared statement] if necessary. This
compile-time option changes that behavior so that [sqlite3_step()] will
- return [SQLITE_MISUSE] if it called again after returning anything other
+ return [SQLITE_MISUSE] if it is called again after returning anything other
than [SQLITE_ROW], [SQLITE_BUSY], or [SQLITE_LOCKED] unless there was an
intervening call to [sqlite3_reset()].
@@ -1714,7 +1710,7 @@
returns. Rather than fix the many defective smartphone applications,
the behavior of SQLite was changed in 3.6.23.2 to automatically reset
- the prepared statement. But that changed caused issues in other
+ the prepared statement. But that change caused issues in other
improperly implemented applications that were actually looking
- for an [SQLITE_MISUSE] return to terminate their query loops. (Anytime
+ for an [SQLITE_MISUSE] return to terminate their query loops. (Any time
an application gets an SQLITE_MISUSE error code from SQLite, that means the
application is misusing the SQLite interface and is thus incorrectly
@@ -1953,7 +1949,6 @@
COMPILE_OPTION {SQLITE_OMIT_PROGRESS_CALLBACK} {
This option may be defined to omit the capability to issue "progress"
- callbacks during long-running SQL statements. The
- [sqlite3_progress_handler()]
- API function is not present in the library.
+ callbacks during long-running SQL statements and removes the
+ [sqlite3_progress_handler()] API function from the library.
}
@@ -1988,5 +1983,5 @@
cache management.
- This compile-time option is recommended most applications as it
+ This compile-time option is recommended for most applications as it
results in improved performance and reduced library footprint.
}
I thought this paragraph could use a slight rewrite, though I'm still a bit dubious as to the quality of the rewrite. However, here it is (in combination with the changes above):
Index: pages/compile.in
==================================================================
--- pages/compile.in
+++ pages/compile.in
@@ -2034,9 +2029,9 @@
COMPILE_OPTION {SQLITE_OMIT_TRUNCATE_OPTIMIZATION} {
- A default build of SQLite, if a [DELETE] statement has no WHERE clause
- and operates on a table with no triggers, an optimization occurs that
- causes the DELETE to occur by dropping and recreating the table.
- Dropping and recreating a table is usually much faster than deleting
- the table content row by row. This is the "truncate optimization".
+ With a default build of SQLite, if a [DELETE] statement has no WHERE clause
+ and operates on a table with no triggers, the [DELETE] will be optimized by
+ dropping and recreating the table, as this is usually much faster than
+ deleting the table content row by row. Enabling this option removes that
+ optimization.
}
I think that's about all that's left for that file, pending other rewrites.
Later, RTDoc brickviking
(Post 65)