@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/07.7.9-conjunct-monotonicity.sqllogic

@@ -0,0 +1,200 @@
+-- conjunct-monotonicity.sqllogic - adding a WHERE conjunct must never widen the result
+--
+-- Regression guard for `bug-primary-key-conjunct-lost-with-correlated-subquery`, and
+-- the generalisation of `bug-filter-conjunct-lost-under-index-order` (pinned next door
+-- in 07.7.5). Both bugs are the same observable class: a conjunct is silently dropped
+-- and the query returns rows the WHERE excluded.
+--
+-- Mechanism of this instance: once `rule-grow-retrieve` equips a Retrieve with an
+-- index-style access plan, that plan is the SOLE authority for what the table access
+-- enforces — `rule-select-access-path` never reads `Retrieve.source`. A correlated
+-- sub-select conjunct is hoisted above the Retrieve as its own Filter, gets rewritten
+-- into a semi join, and join-predicate-pushdown then drops the REMAINING plain conjunct
+-- back down as a bare Filter directly over the already-equipped Retrieve. That fires
+-- grow-retrieve a SECOND time, and its re-probe used to build a request from the new
+-- Filter alone — replacing the committed plan (which was seeking `id = 2`) with an
+-- ordering-only index walk that enforced nothing. Three conjuncts and a CORRELATED
+-- sub-select are both required: with two conjuncts nothing is left over to push back
+-- down, and an uncorrelated sub-select keeps the residual as a single Filter.
+--
+-- Invariant pinned here: the result of a WHERE is monotonically non-increasing in its
+-- conjuncts. For conjuncts K (primary key), N (non-key column) and S (correlated
+-- sub-select), every superset's row set is contained in every subset's. The sweep below
+-- enumerates all seven non-empty subsets, so it covers both known instances and every
+-- shape between them rather than only the one query that was reported.
+
+-- =============================================================================
+-- The sweep. Each conjunct discriminates, so a dropped one is always visible:
+--   K = id = 2                                             -> {2}
+--   N = flag = 1                                           -> {1,2}
+--   S = exists (select 1 from o o2 where o2.id = o.id
+--                 and o2.id < 4)                           -> {1,2,3}
+-- =============================================================================
+
+create table o (id integer primary key, flag integer);
+insert into o values (1, 1), (2, 1), (3, 0), (4, 0);
+
+-- Singletons.
+
+select id from o where id = 2;
+→ [{"id":2}]
+
+select id from o where flag = 1;
+→ [{"id":1},{"id":2}]
+
+select id from o where exists (select 1 from o o2 where o2.id = o.id and o2.id < 4);
+→ [{"id":1},{"id":2},{"id":3}]
+
+-- Pairs. Each must be contained in both of its singletons.
+
+select id from o where id = 2 and flag = 1;
+→ [{"id":2}]
+
+select id from o where id = 2 and exists (select 1 from o o2 where o2.id = o.id and o2.id < 4);
+→ [{"id":2}]
+
+select id from o where flag = 1 and exists (select 1 from o o2 where o2.id = o.id and o2.id < 4);
+→ [{"id":1},{"id":2}]
+
+-- The triple, in every conjunct order. This is the shape that regressed: the answer
+-- must stay {2} no matter which conjunct the planner happens to visit first.
+
+select id from o where id = 2 and flag = 1 and exists (select 1 from o o2 where o2.id = o.id and o2.id < 4);
+→ [{"id":2}]
+
+select id from o where flag = 1 and id = 2 and exists (select 1 from o o2 where o2.id = o.id and o2.id < 4);
+→ [{"id":2}]
+
+select id from o where exists (select 1 from o o2 where o2.id = o.id and o2.id < 4) and flag = 1 and id = 2;
+→ [{"id":2}]
+
+select id from o where flag = 1 and exists (select 1 from o o2 where o2.id = o.id and o2.id < 4) and id = 2;
+→ [{"id":2}]
+
+drop table o;
+
+-- =============================================================================
+-- The reported shapes, verbatim. Every row carries flag = 1 here, so the non-key
+-- conjunct cannot mask a dropped key conjunct: dropping `id = 2` yields all three
+-- rows, which is unmistakable.
+-- =============================================================================
+
+create table o (id integer primary key, flag integer);
+insert into o values (1, 1), (2, 1), (3, 1);
+
+-- Correlated EXISTS on the key column.
+
+select id from o where flag = 1 and id = 2 and exists (select 1 from o o2 where o2.id = o.id);
+→ [{"id":2}]
+
+-- Correlated EXISTS on the NON-key column: a different decorrelation shape.
+
+select id from o where flag = 1 and id = 2 and exists (select 1 from o o2 where o2.flag = o.flag);
+→ [{"id":2}]
+
+-- Correlated scalar sub-select rather than EXISTS.
+
+select id from o where flag = 1 and id = 2 and (select count(*) from o o2 where o2.id = o.id) = 1;
+→ [{"id":2}]
+
+-- The key conjunct written as a single-element IN: extracts as an IN constraint, not '='.
+
+select id from o where flag = 1 and id in (2) and exists (select 1 from o o2 where o2.id = o.id);
+→ [{"id":2}]
+
+-- The sub-select written first.
+
+select id from o where exists (select 1 from o o2 where o2.id = o.id) and flag = 1 and id = 2;
+→ [{"id":2}]
+
+-- BETWEEN: decomposes into a lower and an upper bound sharing ONE source expression.
+-- The de-duplication that keeps the re-probe's unioned constraint list clean must key
+-- on (expression, column, op) — keying on the expression alone collapses these two into
+-- one and silently drops the upper bound.
+
+select id from o where flag = 1 and id between 2 and 2 and exists (select 1 from o o2 where o2.id = o.id);
+→ [{"id":2}]
+
+select id from o where flag = 1 and id between 2 and 3 and exists (select 1 from o o2 where o2.id = o.id);
+→ [{"id":2},{"id":3}]
+
+-- A range key conjunct rather than an equality: keeps more than one row, so a dropped
+-- predicate cannot be mistaken for a correct answer.
+
+select id from o where flag = 1 and id >= 2 and exists (select 1 from o o2 where o2.id = o.id);
+→ [{"id":2},{"id":3}]
+
+-- Aliased table with qualified column references throughout.
+
+select E.id from o E where E.flag = 1 and E.id = 2 and (select count(*) from o T where T.id = E.id) = 1;
+→ [{"id":2}]
+
+-- =============================================================================
+-- Control shapes that were already correct and must stay so: they exercise the
+-- neighbouring paths through the same rule (two conjuncts, constant conjunct,
+-- UNCORRELATED sub-select, absorbed ORDER BY, pushed LIMIT).
+-- =============================================================================
+
+select id from o where id = 2 and exists (select 1 from o o2 where o2.id = o.id);
+→ [{"id":2}]
+
+select id from o where flag = 1 and id = 2 and 1 = 1;
+→ [{"id":2}]
+
+select id from o where flag = 1 and id = 2 and (select count(*) from o o2) = 3;
+→ [{"id":2}]
+
+select id from o where id = 2 order by id;
+→ [{"id":2}]
+
+select id from o where id = 2 order by id desc;
+→ [{"id":2}]
+
+select id from o where id = 2 limit 5;
+→ [{"id":2}]
+
+select id from o where flag = 1 and id = 2 order by id;
+→ [{"id":2}]
+
+-- The full shape with an ORDER BY on top: the Sort re-probes the equipped Retrieve
+-- through the same code path the Filter does, so it must not clobber the seek either.
+
+select id from o where flag = 1 and id = 2 and exists (select 1 from o o2 where o2.id = o.id) order by id;
+→ [{"id":2}]
+
+select id from o where flag = 1 and id >= 2 and exists (select 1 from o o2 where o2.id = o.id) order by id desc;
+→ [{"id":3},{"id":2}]
+
+-- LIMIT on top: LimitOffset is the third operation grow-retrieve can translate into an
+-- index-style context, so it re-probes the committed plan as well.
+
+select id from o where flag = 1 and id >= 2 and exists (select 1 from o o2 where o2.id = o.id) order by id limit 1;
+→ [{"id":2}]
+
+drop table o;
+
+-- =============================================================================
+-- The mutation planner walks the same Retrieve/access-path rules, so a dropped
+-- conjunct there destroys or corrupts rows the WHERE excluded. This is the arm that
+-- makes the bug data-loss rather than a wrong read.
+-- =============================================================================
+
+create table m (id integer primary key, flag integer);
+insert into m values (1, 1), (2, 1), (3, 1);
+
+delete from m where flag = 1 and id = 2 and exists (select 1 from m m2 where m2.id = m.id);
+
+select id, flag from m order by id;
+→ [{"id":1,"flag":1},{"id":3,"flag":1}]
+
+drop table m;
+
+create table m (id integer primary key, flag integer);
+insert into m values (1, 1), (2, 1), (3, 1);
+
+update m set flag = 9 where flag = 1 and id = 2 and exists (select 1 from m m2 where m2.id = m.id);
+
+select id, flag from m order by id;
+→ [{"id":1,"flag":1},{"id":2,"flag":9},{"id":3,"flag":1}]
+
+drop table m;

package/test/logic/07.8-correlated-subquery-edges.sqllogic

@@ -0,0 +1,71 @@
+-- correlated-subquery-edges.sqllogic - Correlated subquery edge cases
+
+-- Setup tables
+create table o (id integer primary key, cat text);
+insert into o values (1, 'X'), (2, 'Y'), (3, 'X');
+
+create table i (id integer primary key, o_id integer null, val integer);
+insert into i values (10, 1, 100), (20, 1, 200), (30, 2, 300), (40, null, 400);
+
+-- ===== Correlated subquery with empty correlation =====
+
+-- Outer row id=3 has no matching inner rows — sum should be null
+select o.id, (select sum(val) from i where i.o_id = o.id) as total from o order by o.id;
+→ [{"id":1,"total":300},{"id":2,"total":300},{"id":3,"total":null}]
+
+-- ===== Multi-level correlation =====
+
+-- Subquery of subquery referencing outermost table
+-- For o.id=1: inner vals 100,200; min=100; count where val>100 = 1
+-- For o.id=2: inner val 300; min=300; count where val>300 = 0
+-- For o.id=3: no inner rows; count = 0
+select o.id,
+  (select count(*) from i i1
+   where i1.o_id = o.id
+   and i1.val > (select min(val) from i i2 where i2.o_id = o.id)
+  ) as cnt
+from o order by o.id;
+→ [{"id":1,"cnt":1},{"id":2,"cnt":0},{"id":3,"cnt":0}]
+
+-- ===== Correlated EXISTS vs IN equivalence =====
+
+-- EXISTS form
+select id from o where exists (select 1 from i where i.o_id = o.id) order by id;
+→ [{"id":1},{"id":2}]
+
+-- IN form (should return same results)
+select id from o where id in (select o_id from i where o_id is not null) order by id;
+→ [{"id":1},{"id":2}]
+
+-- ===== Correlated subquery in different positions =====
+
+-- In SELECT list
+select o.id, (select max(val) from i where i.o_id = o.id) as max_val from o order by o.id;
+→ [{"id":1,"max_val":200},{"id":2,"max_val":300},{"id":3,"max_val":null}]
+
+-- In WHERE
+select * from o where (select count(*) from i where i.o_id = o.id) > 1 order by o.id;
+→ [{"id":1,"cat":"X"}]
+
+-- In HAVING
+select o.cat, count(*) as cnt from o group by o.cat having count(*) > (select 1) order by o.cat;
+→ [{"cat":"X","cnt":2}]
+
+-- Correlated subquery with aggregation that returns NULL for no-match, coalesced
+select o.id, coalesce((select sum(val) from i where i.o_id = o.id), 0) as total from o order by o.id;
+→ [{"id":1,"total":300},{"id":2,"total":300},{"id":3,"total":0}]
+
+-- ===== NOT IN with NULLs in subquery =====
+
+-- Classic SQL gotcha: NOT IN with NULL in subquery list
+-- i has o_id=NULL, so x NOT IN (..., NULL) is UNKNOWN for all x → empty result
+select * from o where id not in (select o_id from i);
+→ []
+
+-- NOT IN excluding NULLs works as expected
+select * from o where id not in (select o_id from i where o_id is not null) order by id;
+→ [{"id":3,"cat":"X"}]
+
+-- Cleanup
+drop table o;
+drop table i;

package/test/logic/07.8.1-correlated-in-decorrelation-gates.sqllogic

@@ -0,0 +1,156 @@
+-- 07.8.1-correlated-in-decorrelation-gates.sqllogic
+--
+-- Regression guard for bug-in-decorrelation-inner-shape-unchecked. A correlated
+-- `col IN (subquery)` gets rewritten by rule-subquery-decorrelation into a semi
+-- join (see rule-subquery-decorrelation.ts). Two assumptions in that rewrite were
+-- unchecked: the join condition was built from the subquery's first OUTPUT
+-- column but the join's right side came from wherever a Project/Alias descent
+-- landed (a mismatch for a COMPUTED projection, whose output column has no base
+-- attribute for the right side to expose), and the descent only recognized
+-- Project/Alias, so DISTINCT / LIMIT / set-ops / ORDER BY above the correlated
+-- filter were silently treated as if absent. Both produced a runtime crash:
+-- "No row context found for column ...". The fix adds gates that decline the
+-- rewrite for all of these shapes, falling back to the correct (if slower)
+-- runtime set-probe IN evaluation — every query below must return the right
+-- answer whether the rule fires or declines.
+--
+-- b.id is a PRIMARY KEY, so `b.id = a.id` matches at most one row — DISTINCT and
+-- LIMIT never change which rows the *plain* correlated shapes return; they are
+-- here to pin that the decline is safe, not to change the result set. id=8
+-- exercises COALESCE actually changing the outcome (a genuine NULL-vs-default
+-- distinction), and the UNION cases append a constant unrelated to correlation
+-- so a wrongly-decorrelated plan (which would silently drop the outer-row
+-- context) is caught by a changed expected result.
+
+create table a (id integer primary key, x integer null);
+create table b (id integer primary key, x integer null);
+
+-- id=3: outer x is NULL (never matches under three-valued IN, regardless of the
+--       inner). id=4: no matching b row (empty subquery). id=5: matching inner
+--       row has NULL x. id=8: matching inner row has NULL x, but outer x = 0 —
+--       distinguishes COALESCE(b.x, 0) from bare b.x.
+insert into a values (1, 10), (2, 20), (3, null), (4, 40), (5, 50), (6, 60), (7, 21), (8, 0);
+insert into b values (1, 10), (2, 20), (3, 30), (5, null), (6, 65), (7, 20), (8, null);
+
+-- ===== Plain correlated IN (the baseline the gated shapes are compared to) =====
+
+select a.x from a where a.x in (select b.x from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- ===== Computed inner projection: the right side's attribute id is fresh, so =====
+-- ===== the join-key-exposure gate must decline (defect 1) =====
+
+select a.x from a where a.x in (select b.x + 0 from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- Computed projection with a residual inner-only predicate alongside the
+-- correlation (b.x > 5 excludes the id=5/id=8 NULL rows via WHERE's NULL drop)
+select a.x from a where a.x in (select b.x * 1 from b where b.id = a.id and b.x > 5) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- COALESCE: id=8's inner NULL becomes 0, matching outer x=0 — only correct if
+-- the computed projection's own value (not some other column) is compared
+select a.x from a where a.x in (select coalesce(b.x, 0) from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20},{"x":0}]
+
+-- ===== DISTINCT / LIMIT above the correlated filter: descent used to stop =====
+-- ===== silently with no inner FilterNode found (defect 2) =====
+
+select a.x from a where a.x in (select distinct b.x from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20}]
+
+select a.x from a where a.x in (select b.x from b where b.id = a.id limit 1) order by a.id;
+→ [{"x":10},{"x":20}]
+
+select a.x from a where a.x in (select b.x from b where b.id = a.id limit 1 offset 0) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- ===== Set operations / ORDER BY above the correlated filter =====
+
+-- UNION appends a constant (40) unrelated to any a.id's correlation; id=4 (no
+-- matching b row) picks it up only because IN evaluates per-row, not because
+-- the rewrite silently dropped the correlation
+select a.x from a where a.x in (select b.x from b where b.id = a.id union select 40) order by a.id;
+→ [{"x":10},{"x":20},{"x":40}]
+
+select a.x from a where a.x in (select b.x from b where b.id = a.id union all select 40) order by a.id;
+→ [{"x":10},{"x":20},{"x":40}]
+
+select a.x from a where a.x in (select b.x from b where b.id = a.id order by b.x) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- ===== The inner *derived table* still decorrelates: only the outer subquery =====
+-- ===== root's own shape gates the rewrite, not an uncorrelated shape nested =====
+-- ===== further inside =====
+
+select a.x from a where a.x in (select t.x from (select * from b) t where t.id = a.id) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- ===== Two correlated IN conjuncts in one WHERE: exercises the rule's internal =====
+-- ===== per-conjunct loop (each becomes its own stacked semi join) =====
+
+select a.x from a where a.x in (select b.x from b where b.id = a.id) and a.x in (select b.x + 0 from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- ===== NOT IN: parses as NOT over the InNode, so it never matches the rule's =====
+-- ===== top-level-conjunct shape and always stays on the per-row path — pinned =====
+-- ===== here for NULL-semantics correctness across the same inner shapes =====
+
+select a.x from a where a.x not in (select b.x from b where b.id = a.id) order by a.id;
+→ [{"x":40},{"x":60},{"x":21}]
+
+select a.x from a where a.x not in (select b.x + 0 from b where b.id = a.id) order by a.id;
+→ [{"x":40},{"x":60},{"x":21}]
+
+-- ===== NOT EXISTS over the same gated inner shapes (existence only, so the =====
+-- ===== presence/absence of a matching b row is what matters) =====
+
+select a.x from a where not exists (select distinct 1 from b where b.id = a.id) order by a.id;
+→ [{"x":40}]
+
+select a.x from a where not exists (select 1 from b where b.id = a.id limit 1) order by a.id;
+→ [{"x":40}]
+
+-- ===== More inner roots the Project/Alias descent cannot step through. Each =====
+-- ===== leaves the correlated filter buried below, so the external-reference =====
+-- ===== backstop declines and the per-row path answers. =====
+
+-- CTE body inside the subquery
+select a.x from a where a.x in (with c as (select b.x from b where b.id = a.id) select c.x from c) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- aggregate root (one row per outer row, so IN sees a single value)
+select a.x from a where a.x in (select max(b.x) from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- grouped root
+select a.x from a where a.x in (select b.x from b where b.id = a.id group by b.x) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- window function in the inner projection
+select a.x from a where a.x in (select max(b.x) over () from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20}]
+
+-- EXCEPT / INTERSECT (the set-op cases beyond UNION)
+select a.x from a where a.x in (select b.x from b where b.id = a.id except select 99) order by a.id;
+→ [{"x":10},{"x":20}]
+
+select a.x from a where a.x in (select b.x from b where b.id = a.id intersect select 10) order by a.id;
+→ [{"x":10}]
+
+-- ===== Plain (non-negated) EXISTS over the same gated inner shapes: the =====
+-- ===== external-reference backstop sits on the shared correlated arm, so it =====
+-- ===== gates the EXISTS rewrite too. Every a row with a matching b row. =====
+
+select a.x from a where exists (select distinct b.x from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20},{"x":null},{"x":50},{"x":60},{"x":21},{"x":0}]
+
+select a.x from a where exists (select b.x + 0 from b where b.id = a.id) order by a.id;
+→ [{"x":10},{"x":20},{"x":null},{"x":50},{"x":60},{"x":21},{"x":0}]
+
+-- UNION arm adds a row unconditionally, so EXISTS is true for every a row
+select a.x from a where exists (select b.x from b where b.id = a.id union select 40) order by a.id;
+→ [{"x":10},{"x":20},{"x":null},{"x":40},{"x":50},{"x":60},{"x":21},{"x":0}]
+
+drop table a;
+drop table b;

package/test/logic/07.9-in-value-list.sqllogic

@@ -0,0 +1,154 @@
+-- in-value-list.sqllogic - `WHERE col IN (<value-list>)` set-membership regression.
+--
+-- Regression for the memory-vtab IN multi-seek (plan=5): a duplicate literal
+-- multiplied matching rows (bag, not set) and a NULL list element fell through
+-- to a full-index walk (spurious non-matching rows). The fix lives in
+-- scanLayer's multi-seek branch (src/vtab/memory/layer/scan-layer.ts): skip
+-- NULL/NULL-containing seek keys and dedup yielded rows by primary key.
+--
+-- These assertions are pure set-membership (counts + exact rows), so they hold
+-- on both the memory module (multi-seek path, indexed columns) and the store
+-- module (residual scalar IN filter). Indexed columns below force the multi-seek
+-- path under the default memory module; the non-indexed table exercises the
+-- residual-filter path in the same run.
+
+create table t (k integer primary key, v integer unique);
+insert into t values (1, 5), (2, 7);
+
+-- ===== Single-value baseline (correct before and after the fix) =====
+
+select k, v from t where v in (5);
+→ [{"k":1,"v":5}]
+
+-- ===== Single-value NULL equality (plan=2 point-seek) returns zero rows =====
+-- `col = null` is UNKNOWN ⇒ no rows. Regression for the point-seek branch of
+-- scanLayer, where a NULL equality key fell through to the full-index walk and
+-- returned every row (fix/in-null-equality-returns-all-rows). Covers the unique
+-- secondary index (v) and the primary key (k) on the memory module, plus the
+-- residual-filter path on the store module.
+
+select k, v from t where v in (null);
+→ []
+
+select k, v from t where v = null;
+→ []
+
+select k, v from t where k = null;
+→ []
+
+select k, v from t where k in (null);
+→ []
+
+-- ===== (a) Duplicate literal must not multiply the matching row =====
+
+select k, v from t where v in (5, 5);
+→ [{"k":1,"v":5}]
+
+-- ===== (b) NULL element contributes no match (no full-scan fallthrough) =====
+
+select k, v from t where v in (5, null);
+→ [{"k":1,"v":5}]
+
+-- ===== (c) Duplicates and NULL combined =====
+
+select k, v from t where v in (5, null, 5, 9);
+→ [{"k":1,"v":5}]
+
+select v from t where v in (5, 5, 9);
+→ [{"v":5}]
+
+-- A duplicate that matches no row stays empty (not a spurious full scan).
+select k, v from t where v in (9, 9, null) order by k;
+→ []
+
+-- Two distinct matching values, each duplicated → each row exactly once.
+select k, v from t where v in (5, 5, 7, 7) order by k;
+→ [{"k":1,"v":5},{"k":2,"v":7}]
+
+-- ===== (d) IN on the PRIMARY KEY column (also multi-seeks) =====
+
+select k, v from t where k in (1, 1, 2, null) order by k;
+→ [{"k":1,"v":5},{"k":2,"v":7}]
+
+select k from t where k in (1, 2, 2) order by k;
+→ [{"k":1},{"k":2}]
+
+-- ===== (f) Same WHERE with and without DISTINCT must agree =====
+
+select v from t where v in (5, null, 5, 9);
+→ [{"v":5}]
+
+select distinct v from t where v in (5, null, 5, 9);
+→ [{"v":5}]
+
+select distinct k, v from t where v in (5, 5, 7, 7) order by k;
+→ [{"k":1,"v":5},{"k":2,"v":7}]
+
+drop table t;
+
+-- ===== Fuzz counterexample shape: REAL UNIQUE index, 0 / NULL / dup / 820 =====
+
+create table t1 (id integer primary key, c_real2 real unique);
+insert into t1 values (1, 0.0), (2, 820.0), (3, -79.79), (4, 100.0);
+
+-- Exactly the rows whose c_real2 ∈ {0, 820}, once each — no duplicate-0 row,
+-- no spurious -79.79/100 row from the NULL element.
+select id, c_real2 from t1 where c_real2 in (0, null, 0, 820) order by id;
+→ [{"id":1,"c_real2":0},{"id":2,"c_real2":820}]
+
+select distinct id, c_real2 from t1 where c_real2 in (0, null, 0, 820) order by id;
+→ [{"id":1,"c_real2":0},{"id":2,"c_real2":820}]
+
+drop table t1;
+
+-- ===== (e) Composite-index IN (cross-product) with a duplicate and a NULL =====
+-- Lives in 07.9.1-in-value-list-composite-index: the composite seek needs a
+-- standalone `create index`, where every scenario here reaches the multi-seek
+-- through an inline PRIMARY KEY / UNIQUE column.
+
+-- ===== Non-indexed column: residual scalar IN filter path =====
+-- w has no index, so IN stays a residual InNode filter rather than a multi-seek.
+-- Duplicates/NULL must behave identically: each base row tested once.
+
+create table t2 (k integer primary key, w integer);
+insert into t2 values (1, 5), (2, 7), (3, 5);
+
+select k, w from t2 where w in (5, 5) order by k;
+→ [{"k":1,"w":5},{"k":3,"w":5}]
+
+select k, w from t2 where w in (5, null) order by k;
+→ [{"k":1,"w":5},{"k":3,"w":5}]
+
+select distinct w from t2 where w in (5, null, 5, 9) order by w;
+→ [{"w":5}]
+
+drop table t2;
+
+-- ===== BLOB constant value list (bug-in-subquery-blob-values-crash) =====
+-- This path pre-builds a BTree at plan-emit time, so a BLOB element crashed
+-- unconditionally, even before any row was scanned: inheritree freezes each
+-- stored entry by default, and Object.freeze throws on a non-empty
+-- Uint8Array, which is exactly what a BLOB scalar is.
+
+create table t3 (id integer primary key, b blob null);
+insert into t3 values (1, x'6162'), (2, x'6164'), (3, null);
+
+select id from t3 where b in (x'6162', x'6164') order by id;
+→ [{"id":1},{"id":2}]
+
+-- A NULL list element contributes no match, but turns a miss into NULL
+select id from t3 where b in (x'6162', null) order by id;
+→ [{"id":1}]
+
+select id, b in (x'6162', null) as r from t3 order by id;
+→ [{"id":1,"r":true},{"id":2,"r":null},{"id":3,"r":null}]
+
+-- Empty BLOB literal x'' is a distinct, valid zero-length value, not NULL:
+-- a miss against a NULL-bearing list is still NULL, and it matches itself.
+select x'' in (x'6162', null) as r;
+→ [{"r":null}]
+
+select x'' in (x'', x'6162') as r;
+→ [{"r":true}]
+
+drop table t3;

package/test/logic/07.9.1-in-value-list-composite-index.sqllogic

@@ -0,0 +1,38 @@
+-- 07.9.1-in-value-list-composite-index.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 07.9-in-value-list: every other scenario there reaches the IN
+-- multi-seek path through an inline PRIMARY KEY or UNIQUE column (auto-indexed),
+-- so the file needs no index DDL. This one scenario builds a standalone composite
+-- `create index` to reach the two-column cross-product form of the same seek, and
+-- would otherwise have cost a backend without first-class CREATE INDEX the entire
+-- IN-value-list file.
+--
+-- Subject: the memory-vtab IN multi-seek over a COMPOSITE index — the a×b seek-key
+-- cross-product must drop NULL-bearing tuples and dedup by primary key, so duplicate
+-- list values never multiply matches.
+
+-- ===== Composite-index IN (cross-product) with a duplicate and a NULL =====
+
+create table c (id integer primary key, a integer, b integer);
+create index idx_ab on c(a, b);
+insert into c values (1, 1, 10), (2, 1, 20), (3, 2, 10), (4, 2, 20);
+
+-- Cross-product (a∈{1,1} × b∈{10,null}): the NULL-bearing tuples drop, the
+-- (1,10) duplicate collapses → a single row.
+select id from c where a in (1, 1) and b in (10, null) order by id;
+→ [{"id":1}]
+
+-- Duplicate values on both columns must not multiply matches.
+select id from c where a in (1, 2, 2) and b in (10, 20, 20) order by id;
+→ [{"id":1},{"id":2},{"id":3},{"id":4}]
+
+-- Duplicate + NULL collapsing to a two-row subset.
+select id from c where a in (1, 1, 2) and b in (10, null) order by id;
+→ [{"id":1},{"id":3}]
+
+select distinct id from c where a in (1, 1, 2) and b in (10, null) order by id;
+→ [{"id":1},{"id":3}]
+
+drop table c;