@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/04-transactions.sqllogic

@@ -0,0 +1,239 @@
+-- transactions.sqllogic - Testing BEGIN, COMMIT, ROLLBACK, SAVEPOINT, and implicit transactions
+
+-- ===================================
+-- Implicit Transaction Tests
+-- ===================================
+-- When not in an explicit transaction (autocommit mode), each statement
+-- is its own implicit-transaction boundary — matching SQLite's autocommit
+-- semantics. A later statement's failure does NOT roll back prior
+-- statements that already committed in the same `exec` batch.
+
+CREATE TABLE implicit_tx (id INTEGER PRIMARY KEY, val TEXT);
+
+-- Single statement should auto-commit
+INSERT INTO implicit_tx VALUES (1, 'auto-committed');
+SELECT val FROM implicit_tx WHERE id = 1;
+→ [{ "val": "auto-committed" }]
+
+-- Multiple statements in one exec each auto-commit on success.
+INSERT INTO implicit_tx VALUES (2, 'batch-a');
+INSERT INTO implicit_tx VALUES (3, 'batch-b');
+INSERT INTO implicit_tx VALUES (4, 'batch-c');
+SELECT count(*) as cnt FROM implicit_tx;
+→ [{ "cnt": 4 }]
+
+-- Error in batch: each statement is its own commit boundary. The first
+-- statement commits, the second statement's duplicate-key failure rolls
+-- back ONLY that statement, and the third statement never runs.
+INSERT INTO implicit_tx VALUES (10, 'new1');
+INSERT INTO implicit_tx VALUES (1, 'duplicate');
+INSERT INTO implicit_tx VALUES (11, 'new2');
+-- error: UNIQUE constraint failed
+
+-- Verify per-statement commit boundary: row 10 (committed) survives, row 11 (never ran) does not.
+SELECT count(*) as cnt FROM implicit_tx WHERE id = 10;
+→ [{ "cnt": 1 }]
+SELECT count(*) as cnt FROM implicit_tx WHERE id = 11;
+→ [{ "cnt": 0 }]
+
+-- Original data still intact plus the surviving (10, 'new1') row.
+SELECT count(*) as cnt FROM implicit_tx;
+→ [{ "cnt": 5 }]
+
+DROP TABLE implicit_tx;
+
+-- ===================================
+-- Explicit Transaction Tests
+-- ===================================
+
+CREATE TABLE tx_t (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO tx_t VALUES (1, 'initial');
+
+-- Basic COMMIT
+BEGIN TRANSACTION;
+INSERT INTO tx_t VALUES (2, 'tx1');
+SELECT val FROM tx_t WHERE id = 2;
+→ [{ "val": "tx1" }]
+COMMIT;
+SELECT val FROM tx_t WHERE id = 2;
+→ [{ "val": "tx1" }]
+
+-- Basic ROLLBACK
+BEGIN TRANSACTION;
+UPDATE tx_t SET val = 'tx2_update' WHERE id = 1;
+INSERT INTO tx_t VALUES (3, 'tx2');
+SELECT val FROM tx_t WHERE id = 1;
+→ [{ "val": "tx2_update" }]
+SELECT val FROM tx_t WHERE id = 3;
+→ [{ "val": "tx2" }]
+ROLLBACK;
+SELECT val FROM tx_t WHERE id = 1;
+→ [{ "val": "initial" }]
+SELECT count(*) FROM tx_t WHERE id = 3;
+→ [{ "count(*)": 0 }]
+
+-- SAVEPOINT and RELEASE
+BEGIN TRANSACTION;
+INSERT INTO tx_t VALUES (4, 'before_sp1');
+SAVEPOINT sp1;
+INSERT INTO tx_t VALUES (5, 'after_sp1');
+SELECT val FROM tx_t WHERE id = 5;
+→ [{ "val": "after_sp1" }]
+RELEASE SAVEPOINT sp1;
+-- sp1 is now merged into the main transaction
+COMMIT;
+SELECT val FROM tx_t WHERE id = 4;
+→ [{ "val": "before_sp1" }]
+SELECT val FROM tx_t WHERE id = 5;
+→ [{ "val": "after_sp1" }]
+
+-- SAVEPOINT and ROLLBACK TO
+BEGIN TRANSACTION;
+UPDATE tx_t SET val = 'tx3_update' WHERE id = 1;
+SAVEPOINT sp2;
+INSERT INTO tx_t VALUES (6, 'after_sp2');
+DELETE FROM tx_t WHERE id = 2;
+SELECT count(*) FROM tx_t WHERE id = 6;
+→ [{ "count(*)": 1 }]
+SELECT count(*) FROM tx_t WHERE id = 2;
+→ [{ "count(*)": 0 }]
+ROLLBACK TO SAVEPOINT sp2;
+-- Changes after sp2 are undone
+SELECT count(*) FROM tx_t WHERE id = 6;
+→ [{ "count(*)": 0 }]
+SELECT count(*) FROM tx_t WHERE id = 2; -- Should be back
+→ [{ "count(*)": 1 }]
+SELECT val FROM tx_t WHERE id = 1; -- Update before sp2 remains
+→ [{ "val": "tx3_update" }]
+COMMIT;
+SELECT val FROM tx_t WHERE id = 1;
+→ [{ "val": "tx3_update" }]
+SELECT count(*) FROM tx_t WHERE id = 6;
+→ [{ "count(*)": 0 }]
+
+-- ===================================
+-- Nested Savepoints
+-- ===================================
+-- ROLLBACK TO s1 should discard s2 and everything after s1.
+
+BEGIN;
+INSERT INTO tx_t VALUES (100, 'a');
+SAVEPOINT s1;
+INSERT INTO tx_t VALUES (101, 'b');
+SAVEPOINT s2;
+INSERT INTO tx_t VALUES (102, 'c');
+ROLLBACK TO s1;
+SELECT count(*) FROM tx_t WHERE id > 99;
+→ [{ "count(*)": 1 }]
+COMMIT;
+
+-- Verify after commit
+SELECT count(*) FROM tx_t WHERE id >= 100;
+→ [{ "count(*)": 1 }]
+SELECT val FROM tx_t WHERE id = 100;
+→ [{ "val": "a" }]
+
+-- Clean up nested test data
+DELETE FROM tx_t WHERE id >= 100;
+-- run
+
+-- ===================================
+-- ROLLBACK TO non-existent savepoint (should error)
+-- ===================================
+
+BEGIN;
+INSERT INTO tx_t VALUES (200, 'phantom');
+ROLLBACK TO SAVEPOINT no_such_sp;
+-- error: No such savepoint: no_such_sp
+
+ROLLBACK;
+-- run
+
+-- ===================================
+-- RELEASE non-existent savepoint (should error)
+-- ===================================
+
+BEGIN;
+INSERT INTO tx_t VALUES (200, 'phantom');
+RELEASE SAVEPOINT no_such_sp;
+-- error: No such savepoint: no_such_sp
+
+ROLLBACK;
+-- run
+
+-- ===================================
+-- Same-prefix savepoint names (no collision)
+-- ===================================
+
+BEGIN;
+SAVEPOINT sp;
+INSERT INTO tx_t VALUES (300, 'sp-data');
+SAVEPOINT spa;
+INSERT INTO tx_t VALUES (301, 'spa-data');
+ROLLBACK TO SAVEPOINT spa;
+-- Only spa's changes are undone; sp's data remains
+SELECT count(*) FROM tx_t WHERE id = 300;
+→ [{ "count(*)": 1 }]
+SELECT count(*) FROM tx_t WHERE id = 301;
+→ [{ "count(*)": 0 }]
+RELEASE SAVEPOINT spa;
+RELEASE SAVEPOINT sp;
+COMMIT;
+
+-- Verify
+SELECT val FROM tx_t WHERE id = 300;
+→ [{ "val": "sp-data" }]
+
+-- Clean up
+DELETE FROM tx_t WHERE id >= 300;
+-- run
+
+-- ===================================
+-- ROLLBACK TO preserves the savepoint (can release after rollback)
+-- ===================================
+
+BEGIN;
+SAVEPOINT preserve_test;
+INSERT INTO tx_t VALUES (400, 'will-be-undone');
+ROLLBACK TO SAVEPOINT preserve_test;
+-- Savepoint still exists; should be able to release it
+RELEASE SAVEPOINT preserve_test;
+COMMIT;
+
+SELECT count(*) FROM tx_t WHERE id = 400;
+→ [{ "count(*)": 0 }]
+
+-- ===================================
+-- Nested savepoints unwinding correctly
+-- ===================================
+
+BEGIN;
+INSERT INTO tx_t VALUES (500, 'base');
+SAVEPOINT sp_outer;
+INSERT INTO tx_t VALUES (501, 'sp_outer');
+SAVEPOINT sp_middle;
+INSERT INTO tx_t VALUES (502, 'sp_middle');
+SAVEPOINT sp_inner;
+INSERT INTO tx_t VALUES (503, 'sp_inner');
+
+-- Rollback to sp_middle should discard sp_inner and sp_middle's changes
+ROLLBACK TO SAVEPOINT sp_middle;
+SELECT count(*) FROM tx_t WHERE id = 503;
+→ [{ "count(*)": 0 }]
+SELECT count(*) FROM tx_t WHERE id = 502;
+→ [{ "count(*)": 0 }]
+-- sp_outer's insert and base should still be visible
+SELECT count(*) FROM tx_t WHERE id = 501;
+→ [{ "count(*)": 1 }]
+SELECT count(*) FROM tx_t WHERE id = 500;
+→ [{ "count(*)": 1 }]
+
+RELEASE SAVEPOINT sp_middle;
+RELEASE SAVEPOINT sp_outer;
+COMMIT;
+
+-- Verify final state
+SELECT count(*) FROM tx_t WHERE id >= 500;
+→ [{ "count(*)": 2 }]
+
+DROP TABLE tx_t;

package/test/logic/04a-savepoint-lazy-attach.sqllogic

@@ -0,0 +1,122 @@
+-- 04a-savepoint-lazy-attach.sqllogic
+-- Regression coverage for the case where a SAVEPOINT is created before a
+-- table's VirtualTableConnection has been registered with the database.
+--
+-- For modules whose connections register lazily on first read/write
+-- (memory module, isolation layer, etc.), the active savepoint stack must
+-- be replayed onto the new connection so that subsequent ROLLBACK TO /
+-- RELEASE broadcasts targeting earlier depths land on real entries rather
+-- than silently no-op'ing on an out-of-range index.
+
+-- ===================================
+-- Case 1: SAVEPOINT before any access on a never-touched table
+-- ===================================
+
+CREATE TABLE t1 (id INTEGER PRIMARY KEY, v TEXT);
+-- run
+
+BEGIN;
+SAVEPOINT sp;
+INSERT INTO t1 VALUES (1, 'x');
+-- visible inside the savepoint
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 1 }]
+ROLLBACK TO SAVEPOINT sp;
+-- the INSERT must be undone
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 0 }]
+ROLLBACK;
+
+-- Outside the transaction the table is still empty
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 0 }]
+
+-- ===================================
+-- Case 2: Nested savepoints before any access; ROLLBACK TO outer + RELEASE outer
+-- ===================================
+
+BEGIN;
+SAVEPOINT outer_sp;
+SAVEPOINT inner_sp;
+INSERT INTO t1 VALUES (10, 'y');
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 1 }]
+ROLLBACK TO SAVEPOINT outer_sp;
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 0 }]
+RELEASE SAVEPOINT outer_sp;
+COMMIT;
+
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 0 }]
+
+-- ===================================
+-- Case 3: Prior committed write + nested savepoint rollbacks
+-- ===================================
+-- Verifies that the existing committed row stays put while nested writes
+-- inside lazily-attached transactions are correctly undone at each level.
+
+INSERT INTO t1 VALUES (100, 'committed');
+-- run
+
+BEGIN;
+SAVEPOINT outer_sp;
+INSERT INTO t1 VALUES (101, 'outer-era');
+SAVEPOINT inner_sp;
+INSERT INTO t1 VALUES (102, 'inner-era');
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 3 }]
+ROLLBACK TO SAVEPOINT inner_sp;
+-- inner-era gone, outer-era stays
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 2 }]
+SELECT v FROM t1 WHERE id = 101;
+→ [{ "v": "outer-era" }]
+ROLLBACK TO SAVEPOINT outer_sp;
+-- outer-era now gone too; committed row remains
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 1 }]
+SELECT v FROM t1 WHERE id = 100;
+→ [{ "v": "committed" }]
+COMMIT;
+
+-- After commit, only the originally-committed row survives
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 1 }]
+SELECT v FROM t1 WHERE id = 100;
+→ [{ "v": "committed" }]
+
+-- Clean up
+DELETE FROM t1;
+-- run
+
+-- ===================================
+-- Case 4: SELECT before SAVEPOINT (isolation-specific)
+-- ===================================
+-- The SELECT registers an IsolatedConnection for t1 before the savepoint, so
+-- onConnectionSavepoint fires and populates savepointsBeforeOverlay. The
+-- subsequent INSERT creates the overlay lazily, and ROLLBACK TO sp must wipe
+-- it. This exercises the pre-existing pre-overlay path which remains live as
+-- a secondary guard alongside the registerConnection replay.
+
+INSERT INTO t1 VALUES (200, 'pre-tx');
+-- run
+
+BEGIN;
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 1 }]
+SAVEPOINT sp;
+INSERT INTO t1 VALUES (201, 'will-vanish');
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 2 }]
+ROLLBACK TO SAVEPOINT sp;
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 1 }]
+SELECT v FROM t1 WHERE id = 200;
+→ [{ "v": "pre-tx" }]
+COMMIT;
+
+SELECT count(*) FROM t1;
+→ [{ "count(*)": 1 }]
+
+DROP TABLE t1;

package/test/logic/05-vtab_memory.sqllogic

@@ -0,0 +1,50 @@
+-- vtab_memory.sqllogic - Testing MemoryTable specific features, especially access paths
+
+PRAGMA default_vtab_module='memory';
+
+-- Setup with PRIMARY KEY and another index potential
+CREATE TABLE mem_t (id INTEGER PRIMARY KEY, name TEXT, age INTEGER, city TEXT);
+INSERT INTO mem_t VALUES (1, 'Alice', 30, 'New York'), (2, 'Bob', 25, 'London'), (3, 'Charlie', 35, 'New York'), (4, 'David', 30, 'Paris');
+
+-- Expect PK point lookup (idxNum=1 likely)
+-- NOTE: We can't directly assert idxNum here, but verify behavior
+SELECT * FROM mem_t WHERE id = 3;
+→ [{"id":3,"name":"Charlie","age":35,"city":"New York"}]
+
+-- Expect PK range scan
+SELECT name FROM mem_t WHERE id > 1 AND id < 4 ORDER BY id;
+→ [{"name":"Bob"},{"name":"Charlie"}]
+
+-- Expect full table scan (no usable index on name directly for EQ)
+SELECT id FROM mem_t WHERE name = 'Bob';
+→ [{"id":2}]
+
+-- ORDER BY PK should be consumed by index scan
+SELECT id FROM mem_t WHERE id > 1 ORDER BY id LIMIT 2;
+→ [{"id":2},{"id":3}]
+
+-- ORDER BY non-indexed column requires VDBE sort
+SELECT id FROM mem_t ORDER BY age, name;
+→ [{"id":2},{"id":1},{"id":4},{"id":3}]
+
+-- Filter and Order interaction
+SELECT name FROM mem_t WHERE city = 'New York' ORDER BY age;
+→ [{"name":"Alice"},{"name":"Charlie"}]
+
+-- Test transactions (covered more in transactions.sqllogic, but include a basic check)
+BEGIN;
+INSERT INTO mem_t VALUES (5, 'Eve', 28, 'London');
+SELECT count(*) FROM mem_t WHERE city = 'London';
+→ [{ "count(*)": 2 }]
+ROLLBACK;
+SELECT count(*) FROM mem_t WHERE city = 'London';
+→ [{ "count(*)": 1 }]
+
+-- Test multiple constraints - PK likely preferred
+SELECT name FROM mem_t WHERE id > 1 AND age = 30;
+→ [{"name":"David"}]
+
+DROP TABLE mem_t;
+
+-- Explicit unique-index collation governing enforcement lives in
+-- 05.0.1-vtab-memory-unique-index-collation (it needs standalone CREATE INDEX).

package/test/logic/05.0.1-vtab-memory-unique-index-collation.sqllogic

@@ -0,0 +1,34 @@
+-- 05.0.1-vtab-memory-unique-index-collation.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 05-vtab_memory: that file's subject is MemoryTable access-path
+-- behavior (PK point lookup, PK range scan, full scan, ORDER BY consumption,
+-- transactions), none of which needs index DDL. This trailing section was the
+-- file's only `create unique index`, and kept a backend without standalone index
+-- DDL from running any of the access-path coverage.
+--
+-- Subject: a unique index declaring a COARSER collation than its column unifies
+-- case-variants — enforcement runs through the index's comparator, and the
+-- conflict validator re-compares candidates under the index's per-column
+-- collation (checkUniqueViaIndex) — re-checking under the column's BINARY
+-- collation would skip the case-variants the index legitimately unifies.
+-- (The converse — a FINER index over a NOCASE column admitting both
+-- variants — is pinned by test/planner/collation-soundness.spec.ts.)
+
+PRAGMA default_vtab_module='memory';
+
+CREATE TABLE mem_uci (id INTEGER PRIMARY KEY, b TEXT);
+CREATE UNIQUE INDEX mem_uci_b ON mem_uci (b COLLATE NOCASE);
+INSERT INTO mem_uci VALUES (1, 'Bob');
+
+-- a case-variant collides under the index's NOCASE collation
+INSERT INTO mem_uci VALUES (2, 'BOB');
+-- error: UNIQUE constraint failed
+
+-- a genuinely different value still inserts
+INSERT INTO mem_uci VALUES (3, 'Carol');
+SELECT id, b FROM mem_uci ORDER BY id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"}]
+
+DROP TABLE mem_uci;

package/test/logic/05.1-composite-pk-range-scan.sqllogic

@@ -0,0 +1,147 @@
+-- 05.1-composite-pk-range-scan.sqllogic
+-- Regression: a range scan with a lower bound on the leading column of a
+-- COMPOSITE primary key must return every matching row, not just the last one.
+-- (The multi-column secondary-index counterpart is 05.1.1-secondary-index-range-scan,
+-- split out because it needs standalone CREATE INDEX.) Previously the memory-table scanner
+-- built a scalar seek key against array-shaped composite keys, mispositioning
+-- the cursor so the ascending scan collapsed to the final row.
+
+PRAGMA default_vtab_module='memory';
+
+-- Composite PK (a, b). BTree keys are arrays [a, b].
+CREATE TABLE t (a INTEGER, b INTEGER, v TEXT, PRIMARY KEY (a, b));
+INSERT INTO t VALUES (10, 0, 'x'), (20, 0, 'y'), (30, 0, 'z');
+
+-- Lower bound below all keys: all rows.
+SELECT a FROM t WHERE a >= 5 ORDER BY a;
+→ [{"a":10},{"a":20},{"a":30}]
+
+-- Lower bound on an exact key (inclusive): all rows from that key.
+SELECT a FROM t WHERE a >= 10 ORDER BY a;
+→ [{"a":10},{"a":20},{"a":30}]
+
+-- Lower bound between keys.
+SELECT a FROM t WHERE a >= 15 ORDER BY a;
+→ [{"a":20},{"a":30}]
+
+-- Exclusive lower bound on an exact key.
+SELECT a FROM t WHERE a > 10 ORDER BY a;
+→ [{"a":20},{"a":30}]
+
+-- Combined lower + upper bound.
+SELECT a FROM t WHERE a >= 10 AND a < 30 ORDER BY a;
+→ [{"a":10},{"a":20}]
+
+-- Upper-bound-only (control: was always correct).
+SELECT a FROM t WHERE a <= 25 ORDER BY a;
+→ [{"a":10},{"a":20}]
+
+DROP TABLE t;
+
+-- Three-column composite PK.
+CREATE TABLE t3 (hlc_ts INTEGER, node_id TEXT, seq INTEGER, v TEXT, PRIMARY KEY (hlc_ts, node_id, seq));
+INSERT INTO t3 VALUES (100, 'n', 0, 'a'), (300, 'n', 0, 'a'), (500, 'n', 0, 'a'), (700, 'n', 0, 'a');
+
+SELECT hlc_ts FROM t3 WHERE hlc_ts >= 0 ORDER BY hlc_ts;
+→ [{"hlc_ts":100},{"hlc_ts":300},{"hlc_ts":500},{"hlc_ts":700}]
+
+SELECT hlc_ts FROM t3 WHERE hlc_ts >= 0 AND hlc_ts < 1000 ORDER BY hlc_ts;
+→ [{"hlc_ts":100},{"hlc_ts":300},{"hlc_ts":500},{"hlc_ts":700}]
+
+SELECT count(*) AS n FROM t3 WHERE hlc_ts >= 0 AND hlc_ts < 1000;
+→ [{"n":4}]
+
+DROP TABLE t3;
+
+-- Single-column PK (control: scalar seek key matches scalar stored keys).
+CREATE TABLE s (id INTEGER PRIMARY KEY, v TEXT);
+INSERT INTO s VALUES (10, 'a'), (20, 'b'), (30, 'c');
+
+SELECT id FROM s WHERE id >= 0 ORDER BY id;
+→ [{"id":10},{"id":20},{"id":30}]
+
+DROP TABLE s;
+
+-- The multi-column SECONDARY index variants of these range scans (ASC- and
+-- DESC-leading) live in 05.1.1-secondary-index-range-scan; they need standalone
+-- CREATE INDEX, everything here works off PRIMARY KEY declarations alone.
+
+-- Composite PRIMARY KEY with a DESC leading column. The primary BTree is
+-- physically ordered with the leading column descending, so an ascending
+-- physical scan must seek from the upper bound and terminate at the lower
+-- bound. Previously the primary branch lacked this handling and dropped every
+-- matching row for a leading-column lower-bound range.
+CREATE TABLE td (a INTEGER, b INTEGER, v TEXT, PRIMARY KEY (a DESC, b));
+INSERT INTO td VALUES (10, 0, 'x'), (20, 0, 'y'), (30, 0, 'z');
+
+-- The originally reported failing query.
+SELECT a FROM td WHERE a >= 15 ORDER BY a;
+→ [{"a":20},{"a":30}]
+
+-- Inclusive lower bound on an exact key.
+SELECT a FROM td WHERE a >= 20 ORDER BY a;
+→ [{"a":20},{"a":30}]
+
+-- Exclusive lower bound on an exact key.
+SELECT a FROM td WHERE a > 20 ORDER BY a;
+→ [{"a":30}]
+
+-- Leading-column range (lower + upper bound).
+SELECT a FROM td WHERE a >= 15 AND a < 30 ORDER BY a;
+→ [{"a":20}]
+
+-- Descending output over a DESC-leading PK with a leading-column bound.
+SELECT a FROM td WHERE a >= 15 ORDER BY a DESC;
+→ [{"a":30},{"a":20}]
+
+-- Descending output combined with a leading-column range.
+SELECT a FROM td WHERE a >= 15 AND a < 30 ORDER BY a DESC;
+→ [{"a":20}]
+
+DROP TABLE td;
+
+-- Three-column composite PRIMARY KEY with a DESC leading column.
+CREATE TABLE td3 (a INTEGER, b TEXT, c INTEGER, v TEXT, PRIMARY KEY (a DESC, b, c));
+INSERT INTO td3 VALUES (100, 'n', 0, 'a'), (300, 'n', 0, 'a'), (500, 'n', 0, 'a'), (700, 'n', 0, 'a');
+
+SELECT a FROM td3 WHERE a >= 250 ORDER BY a;
+→ [{"a":300},{"a":500},{"a":700}]
+
+SELECT a FROM td3 WHERE a >= 250 AND a < 600 ORDER BY a;
+→ [{"a":300},{"a":500}]
+
+SELECT count(*) AS n FROM td3 WHERE a >= 250 AND a < 600;
+→ [{"n":2}]
+
+DROP TABLE td3;
+
+-- DESC-leading PK with DUPLICATE leading-column values. The early-termination
+-- break keys off the leading column only, so it must not truncate sibling rows
+-- that share the boundary value, nor break early while still inside the range.
+CREATE TABLE tdup (a INTEGER, b INTEGER, v TEXT, PRIMARY KEY (a DESC, b));
+INSERT INTO tdup VALUES (20, 1, 'p'), (20, 2, 'q'), (10, 1, 'r'), (30, 1, 's');
+
+-- Lower bound only: both a=20 rows must come through (no premature break at the
+-- first a=20 row), and the scan must stop once it drops below 15.
+SELECT a, b FROM tdup WHERE a >= 15 ORDER BY a, b;
+→ [{"a":20,"b":1},{"a":20,"b":2},{"a":30,"b":1}]
+
+-- Exclusive lower bound landing on a duplicated leading value: every a=20 row is
+-- excluded, the break fires only after exhausting them.
+SELECT a, b FROM tdup WHERE a > 20 ORDER BY a, b;
+→ [{"a":30,"b":1}]
+
+-- Inclusive lower bound on the duplicated value keeps all a=20 rows.
+SELECT count(*) AS n FROM tdup WHERE a >= 20;
+→ [{"n":3}]
+
+-- Upper-bound-only range over a DESC-leading PK (no lower bound → the DESC
+-- early-termination guard never fires; correctness rests on planAppliesToKey).
+SELECT a, b FROM tdup WHERE a < 25 ORDER BY a, b;
+→ [{"a":10,"b":1},{"a":20,"b":1},{"a":20,"b":2}]
+
+-- Inclusive upper bound on an exact (duplicated) key.
+SELECT a, b FROM tdup WHERE a <= 20 ORDER BY a, b;
+→ [{"a":10,"b":1},{"a":20,"b":1},{"a":20,"b":2}]
+
+DROP TABLE tdup;

package/test/logic/05.1.1-secondary-index-range-scan.sqllogic

@@ -0,0 +1,56 @@
+-- 05.1.1-secondary-index-range-scan.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 05.1-composite-pk-range-scan: that file's subject is leading-column
+-- range scans over composite (and DESC-leading composite) PRIMARY KEYS, which need
+-- no index DDL at all. These two scenarios build a standalone multi-column SECONDARY
+-- index purely as a comparison point for the same seek-key bug, so they lived only to
+-- cover the secondary branch — and would have made the whole PK file unrunnable on a
+-- backend without first-class CREATE INDEX.
+--
+-- Subject: a range scan bounded on the leading column of a multi-column SECONDARY
+-- index must return every matching row (ASC-leading and DESC-leading variants).
+
+PRAGMA default_vtab_module='memory';
+
+-- Multi-column SECONDARY index, leading-column range scan. The PK is a single
+-- scalar column so the primary path is unaffected; force the secondary index
+-- to drive the scan via a leading-column range on a composite index.
+CREATE TABLE idx_t (id INTEGER PRIMARY KEY, k INTEGER, name TEXT, v TEXT);
+CREATE INDEX idx_kn ON idx_t (k, name);
+INSERT INTO idx_t VALUES (1, 10, 'a', 'p'), (2, 20, 'b', 'q'), (3, 30, 'c', 'r');
+
+SELECT id FROM idx_t WHERE k >= 10 ORDER BY k;
+→ [{"id":1},{"id":2},{"id":3}]
+
+SELECT id FROM idx_t WHERE k >= 15 ORDER BY k;
+→ [{"id":2},{"id":3}]
+
+SELECT id FROM idx_t WHERE k >= 10 AND k < 30 ORDER BY k;
+→ [{"id":1},{"id":2}]
+
+DROP TABLE idx_t;
+
+-- Multi-column SECONDARY index with a DESC leading column. The secondary
+-- branch carries isDescFirstColumn handling (the lower-bound wrap is
+-- direction-independent), so a leading-column range still returns every row.
+-- (The primary branch lacks this handling — tracked separately.)
+CREATE TABLE idx_d (id INTEGER PRIMARY KEY, k INTEGER, name TEXT, v TEXT);
+CREATE INDEX idx_kn_d ON idx_d (k DESC, name);
+INSERT INTO idx_d VALUES (1, 10, 'a', 'p'), (2, 20, 'b', 'q'), (3, 30, 'c', 'r');
+
+SELECT id FROM idx_d WHERE k >= 15 ORDER BY k;
+→ [{"id":2},{"id":3}]
+
+-- Upper-bound range on the DESC-leading secondary index. An ascending physical
+-- walk over a DESC-leading composite index seeks from the upper bound; that
+-- scalar bound is wrapped in a single-element array so the comparator positions
+-- the seek at the bound rather than at a tree extreme. NOTE: the pre-wrap scalar
+-- form was inefficient (a bare scalar sorts to one tree end, forcing a full
+-- forward scan) but still correct here — it landed at the start of the walk, so
+-- this case is a result-correctness assertion, not a row-drop regression guard.
+SELECT id FROM idx_d WHERE k <= 25 ORDER BY k;
+→ [{"id":1},{"id":2}]
+
+DROP TABLE idx_d;