SQLite catches covering index mistakes before execution

A covering index decision tells later stages of a database engine that the index contains everything a query needs. If that prediction is wrong, generated code can refer to a table cursor the execution program never opened. SQLite 3.46.1 strengthens this boundary by detecting over-prediction early enough for statement preparation to return an error.

The August 13 release improves the prediction itself as well as adding that early detection. The defensive check matters independently of the original correction. A preparation error gives a caller an ordinary failure to handle, while invalid bytecode can fail inside execution with much less useful consequences.

I value SQLite's ability to sit inside an application process, but that also makes a crash in the engine a crash in the application. Rejecting an invalid internal assumption before execution is a useful reliability property for an embedded library. It puts the failure at a boundary the caller already has to handle.

The report combines ordinary database features

The underlying report concerns an update on a WITHOUT ROWID table with a partial unique index. Its predicate uses bound parameters. The reporter found that removing the parameters, removing WITHOUT ROWID, or making the index non-unique avoided the crash in the reduced example.

That combination is informative because none of its individual ingredients is an obviously meaningless operation. The report originated in a data-cleanup query and includes a small reproduction, execution bytecode, and a debugger trace. It demonstrates a failure in the interaction among features, rather than requiring a deliberately malformed database file.

Richard Hipp traced the regression to a September 2023 check-in and identified 3.44.0 as the first affected release. His initial patch response also distinguishes having a small candidate correction from being satisfied with the testing. By August 13, the release note describes both better covering-index prediction and a check that stops bad bytecode generation.

The report does not justify replacing bound parameters with interpolated SQL throughout an application. Its parameter variation helps isolate the planner path that triggers the defect. The released correction belongs to the engine's planning and code generation. Treating one diagnostic variation as a general application design recommendation would draw the wrong conclusion.

Detection limits the consequences of a wrong prediction

A query planner chooses an access strategy before the engine executes its program. Later code relies on properties established during that choice. A covering index is useful because table access can be unnecessary when the index supplies the required values. That saving depends on the coverage claim being true.

The new early check makes the dependency explicit. If later preparation discovers that the prediction was too broad, SQLite can stop preparing the statement. The release specifically contrasts returning an error from sqlite3_prepare() with generating bad bytecode. It therefore improves how the engine contains this class of internal disagreement.

Correct prediction remains preferable because valid application SQL should execute. The defensive check is an additional response if prediction fails. Keeping those goals separate explains why the release includes both changes. Better planning reduces the occurrence, while earlier detection improves the failure mode.

FTS5 now rejects incomplete tokenizer arguments

The same release improves parsing of FTS5's tokenize= arguments. The August 6 report gives two examples involving the trigram tokenizer. Each supplies an option name without the value that should follow it. The resulting null pointer dereference crashes the engine.

One reported statement is short enough to show the missing piece directly. This is invalid configuration, included to explain the failure path.

CREATE VIRTUAL TABLE t USING fts5(
    s,
    tokenize='trigram case_sensitive '
);

The option expects a value after case_sensitive. The report suggests checking argument pairing before accessing that value. An August 8 response confirms that the examples now produce an error from the tokenizer constructor on the corrected development build. The 3.46.1 release records the robustness improvement as a shipped change.

This is a different input boundary from the covering-index problem. The tokenizer must reject incomplete configuration supplied through SQL. The planner check protects an assumption made by the engine itself. Both improve the transition from a requested operation to a valid execution program.

I find these details more useful than a generic claim that the release improves stability. They identify whether the caller should expect a rejected configuration or a corrected valid query. Those outcomes have different meanings for the application consuming the error.

The patch also corrects diagnostic accuracy

Version 3.46.1 fixes false-positive integrity reports in FTS5 secure-delete mode. An integrity checker is useful only if its findings correspond to actual inconsistency. A false report can prompt unnecessary recovery work, so correctness in the diagnostic path deserves attention alongside correctness in ordinary queries.

The release also standardizes syntax errors in ALTER TABLE on SQLITE_ERROR, correcting cases that returned SQLITE_INTERNAL. The operation still fails, but the error category changes what a caller can reasonably infer. An invalid SQL statement should not appear to establish an internal engine failure.

For an application that embeds SQLite, these fixes affect both normal execution and its surrounding error handling. Valid queries get corrected planning behavior, malformed tokenizer options get a constructor error, and diagnostics become more accurate about the reason an operation failed. The preparation check specifically prevents a mistaken coverage assumption from continuing into an invalid execution program.