SQLite 3.53：WAL 破損バグの修正と、CLI にまともな表を
SQLite 3.53 は WAL リセットによるデータベース破損バグを修正し、結果整形ライブラリ QRF を追加し、ALTER TABLE で制約を追加・削除できるようにし、REINDEX EXPRESSIONS を導入した。最後の一つは陳腐化した式インデックスの修復手段。
SQLite 3.53.0 は 2026 年 4 月 9 日に出ました。最重要の項目はリストの先頭にあります。
WAL リセットによるデータベース破損バグを修正。
説明も CVE 番号もありません。しかし SQLite のリリースノートに「データベース破損」の文字が出るなら、大事なデータを預けている人はアップグレードする理由として十分です。
ALTER TABLE が制約を触れるようになった
SQLite の ALTER TABLE は常に限定的でした。列の追加、名前変更、それ以外は手作業でテーブルを作り直す。3.53 からは次ができます。
NOT NULLとCHECK制約の追加NOT NULLとCHECK制約の削除
どちらも他のデータベースでは日常作業で、SQLite では常にマイグレーションスクリプトの最も汚い部分でした。
REINDEX EXPRESSIONS：陳腐化した式インデックスの修復
新しい REINDEX EXPRESSIONS は式インデックスを再構築します。
CREATE INDEX ... ON t(lower(name)) のようなインデックスの厄介さは、内容が式から計算されることです。式が依存する何かが変わると（カスタム関数の実装、COLLATE の挙動など）、保存された値は今の式が生む値と一致しなくなります。クエリは黙って誤った結果を返します。
従来の唯一の手段は DROP INDEX して CREATE INDEX するだけでした。今は専用の文があります。
TEMP トリガがメインスキーマの表に届く
一時表のトリガが、メインスキーマの表を変更・参照できるようになりました。以前はできず、一時表を監査用やシャドウ用に使う書き方が制限されていました。
VACUUM INTO が reserve を指定できる
VACUUM INTO の対象が URI ファイル名で reserve=N（0–255）を含む場合、生成される複製にその reserve が設定されます。些細に見えますが、SQLite の reserve は「各ページ末尾に将来の成長用として何バイト残すか」であり、後の更新がページ分割を強制されるかどうかを左右します。複製時に元の設定に合わせられるのは意味があります。
QRF：CLI についにまともな表が
新しい Query Result Formatter（QRF）ライブラリが、SQL の結果を人間が読める固定幅の表に整形します。TCL インターフェースに format メソッドが加わり、CLI もこれを使います。
具体的には：
- 対話的な CLI セッションの既定出力が QRF になり、Unicode の罫線文字で枠を描く
- 数値は既定で右寄せ
- バッチセッションは従来の形式のまま（スクリプト互換のため）
最後の点は節度です。既定出力を変えると CLI の出力を解析する全スクリプトが壊れるので、人間が見ている場面だけで変えました。
非互換が一つ
ドットコマンド末尾の裸のセミコロンは黙って無視される。
つまり .tables; はエラーにならず .tables として扱われます。公式に「潜在的な非互換」とされています。そのセミコロンがエラーを出すことに依存していたツールは、黙って壊れます。
私の結論
SQLite を使うほとんどのプロジェクトにとって、最初の項目がアップグレードの理由そのものです。WAL リセットは VACUUM、チェックポイント、そしていくつかの復旧経路が触れる仕組みなので、そこにバグがあると通常操作中にも破損しうることを意味します。
REINDEX EXPRESSIONS は二番目に記録しておく価値があります。式インデックスが陳腐化したときの症状はクラッシュではなく黙った誤りです。最も気づきにくい種類のバグであり、専用の再構築コマンドを最も必要とするものです。
コメント
…