@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/07.7.1-in-extras.sqllogic

@@ -0,0 +1,158 @@
+-- adapted from SQLite test/in.test, test/in2.test, test/in4.test, test/in5.test
+-- IN operator surface gaps: row-value (tuple) IN with literal list and subquery,
+-- IN with extra parens around subquery, IN with CASE expression as operand,
+-- DML with IN-subquery filters, and IN list with duplicate values.
+
+create table inx_t (id integer primary key, a integer, b integer);
+insert into inx_t values (1, 1, 10), (2, 2, 20), (3, 3, 30), (4, 4, 40);
+
+-- =============================================================================
+-- Row-value (tuple) IN with literal list — Quereus parser does not support
+-- row-value tuple syntax in IN; convert to error assertion.
+-- =============================================================================
+
+select id from inx_t where (a, b) in ((1, 10), (3, 30), (99, 99)) order by id;
+-- error: Expected ')'
+
+-- =============================================================================
+-- IN with extra parens around subquery: Quereus interprets extra parens as
+-- forcing scalar context, so a multi-row subquery becomes a scalar-error case.
+-- These do not apply.
+-- =============================================================================
+
+-- =============================================================================
+-- IN with CASE expression as operand
+-- =============================================================================
+
+select id, (case when a > 2 then a else a + 100 end) in (101, 102, 3, 4) as matched from inx_t order by id;
+→ [{"id":1,"matched":true},{"id":2,"matched":true},{"id":3,"matched":true},{"id":4,"matched":true}]
+
+-- IN where the list contains expressions
+select id from inx_t where a in (1 + 1, 1 + 2) order by id;
+→ [{"id":2},{"id":3}]
+
+-- =============================================================================
+-- IN list with duplicate values (must dedupe — should not change result)
+-- =============================================================================
+
+select id from inx_t where a in (1, 1, 2, 2, 1) order by id;
+→ [{"id":1},{"id":2}]
+
+-- =============================================================================
+-- UPDATE / DELETE with IN-subquery filter
+-- =============================================================================
+
+create table inx_dml (id integer primary key, val integer);
+insert into inx_dml values (1, 10), (2, 20), (3, 30), (4, 40);
+
+create table inx_keep (id integer primary key);
+insert into inx_keep values (1), (3);
+
+-- UPDATE WHERE id IN (subquery)
+update inx_dml set val = val * 10 where id in (select id from inx_keep);
+select id, val from inx_dml order by id;
+→ [{"id":1,"val":100},{"id":2,"val":20},{"id":3,"val":300},{"id":4,"val":40}]
+
+-- DELETE WHERE id NOT IN (subquery)
+delete from inx_dml where id not in (select id from inx_keep);
+select id, val from inx_dml order by id;
+→ [{"id":1,"val":100},{"id":3,"val":300}]
+
+drop table inx_dml;
+drop table inx_keep;
+
+-- =============================================================================
+-- Single-placeholder `col in (?)` over a PK must match exactly the bound row(s),
+-- never the whole table. Regression for the match-all defect: a one-element
+-- parameterized IN reduced to a point-seek on Literal(undefined) and degraded to
+-- a full-index walk, so `delete from T where pk in (?)` wiped every row.
+-- See quereus-single-element-in-list-matches-all.
+-- =============================================================================
+
+create table inp (id integer primary key, label text);
+insert into inp values (0, 'a'), (1, 'b'), (2, 'c'), (3, 'd');
+
+-- select with a single placeholder matches just the bound row
+-- params: [1]
+select id from inp where id in (?) order by id;
+→ [{"id":1}]
+
+-- a different bind value selects a different single row
+-- params: [2]
+select id from inp where id in (?) order by id;
+→ [{"id":2}]
+
+-- one-, two-, three-placeholder IN agree, and with `= ?`
+-- params: [1, 2]
+select id from inp where id in (?, ?) order by id;
+→ [{"id":1},{"id":2}]
+
+-- params: [0, 2, 3]
+select id from inp where id in (?, ?, ?) order by id;
+→ [{"id":0},{"id":2},{"id":3}]
+
+-- params: [3]
+select id from inp where id = ? order by id;
+→ [{"id":3}]
+
+-- Correlated single-element IN (`p.id in (outer.target)`) — the inner scalar
+-- subquery seeks inp's PK on a correlated outer column. Pre-fix this match-alled,
+-- so the scalar subquery would have seen every row instead of exactly one.
+create table inref (rid integer primary key, target integer);
+insert into inref values (10, 2), (11, 3);
+select o.rid, (select p.label from inp p where p.id in (o.target)) as label from inref o order by o.rid;
+→ [{"rid":10,"label":"c"},{"rid":11,"label":"d"}]
+
+-- Plan-mechanism guard: the single-placeholder IN must reduce to an index seek
+-- whose seek key is the bound ParameterReference — NOT a Literal(undefined). The
+-- defect emitted a Literal node (value undefined) as the seek key, which the scan
+-- layer read as "no constraint" and walked the whole index.
+select count(*) as params from query_plan('select id from inp where id in (?)') where node_type = 'ParameterReference';
+→ [{"params":1}]
+
+select count(*) as lits from query_plan('select id from inp where id in (?)') where node_type = 'Literal';
+→ [{"lits":0}]
+
+-- DESTRUCTIVE: delete with a single placeholder removes ONLY the bound row,
+-- not the whole table.
+-- params: [1]
+delete from inp where id in (?);
+→ []
+
+select id from inp order by id;
+→ [{"id":0},{"id":2},{"id":3}]
+
+-- Composite multi-column seek with a single-element dynamic IN component.
+-- A 2-column PK seek where one column carries a multi-value IN (`a in (1, 2)`)
+-- and the other a single-placeholder IN (`b in (?)`) takes the composite
+-- cross-product seek path. Pre-fix the single-element component was dropped to
+-- Literal(undefined) (match-all on b); it must instead seek on the bound param,
+-- so only the b = <param> rows match.
+create table cmp (a integer, b integer, label text, primary key (a, b));
+insert into cmp values (1, 5, 'a'), (1, 6, 'b'), (2, 5, 'c'), (2, 6, 'd');
+
+-- b bound to 5 selects exactly the b=5 rows across both a values
+-- params: [5]
+select label from cmp where a in (1, 2) and b in (?) order by label;
+→ [{"label":"a"},{"label":"c"}]
+
+-- a different bind picks the other pair (proves the param is not constant-folded)
+-- params: [6]
+select label from cmp where a in (1, 2) and b in (?) order by label;
+→ [{"label":"b"},{"label":"d"}]
+
+-- Plan-mechanism guard: the dynamic component survives into the composite seek as
+-- the bound ParameterReference, not a dropped Literal(undefined). Pre-fix the param
+-- was lost entirely (0 ParameterReference nodes). Asserted as a presence check
+-- rather than an exact count because the seek-key cardinality is module-specific
+-- (the memory module expands the literal `a in (1, 2)` cross-product, emitting the
+-- param once per tuple; the store module keeps a single seek with one param node).
+select case when count(*) >= 1 then 'present' else 'absent' end as param from query_plan('select label from cmp where a in (1, 2) and b in (?)') where node_type = 'ParameterReference';
+→ [{"param":"present"}]
+
+drop table cmp;
+
+drop table inref;
+drop table inp;
+
+drop table inx_t;

package/test/logic/07.7.1-scalar-agg-decorrelation-filter.sqllogic

@@ -0,0 +1,105 @@
+-- 07.7.1-scalar-agg-decorrelation-filter.sqllogic
+-- Correlated scalar-aggregate subqueries used in a WHERE or HAVING comparison
+-- are decorrelated into grouped left joins (rule scalar-agg-decorrelation-filter,
+-- the Filter anchor). A HAVING clause is a FilterNode whose source is an
+-- Aggregate, so one anchor covers both WHERE and HAVING. These tests pin the
+-- observable semantics of the decorrelated shapes AND the shapes the rule must
+-- reject (which stay on the correlated per-row path, still correct).
+
+-- Setup: outer `o` (some rows with no matching child, one NULL correlation key),
+-- child `c` grouped by fk.
+CREATE TABLE o (id INTEGER PRIMARY KEY, k INTEGER NULL, total INTEGER NULL);
+CREATE TABLE c (id INTEGER PRIMARY KEY, fk INTEGER NULL, amount INTEGER NULL);
+
+INSERT INTO o VALUES (1, 10, 8), (2, 20, 3), (3, 30, 100), (4, null, -5), (5, 40, 20);
+INSERT INTO c VALUES (1, 10, 5), (2, 10, 7), (3, 20, 4), (4, 20, 8), (5, 40, 1);
+
+-- Per-o subquery values (avg(amount) / count(*) where c.fk = o.k):
+--   o1 k=10 → {5,7} avg 6, count 2
+--   o2 k=20 → {4,8} avg 6, count 2
+--   o3 k=30 → {}   avg NULL, count 0
+--   o4 k=NULL → {} avg NULL, count 0   (NULL key never matches)
+--   o5 k=40 → {1}  avg 1, count 1
+
+-- WHERE comparison against a correlated avg: three-valued logic preserved by the
+-- LEFT-join NULL-pad (o.total > NULL → NULL → row excluded).
+SELECT o.id, o.total FROM o WHERE o.total > (SELECT avg(c.amount) FROM c WHERE c.fk = o.k) ORDER BY o.id;
+→ [{"id":1,"total":8},{"id":5,"total":20}]
+
+-- WHERE against a correlated count: the empty group must yield 0 (non-NULL empty
+-- value → CASE marker path), so a no-match outer row SURVIVES the filter rather
+-- than being dropped. This is the count-bug analogue for the Filter anchor.
+SELECT o.id, o.total FROM o WHERE (SELECT count(*) FROM c WHERE c.fk = o.k) = 0 ORDER BY o.id;
+→ [{"id":3,"total":100},{"id":4,"total":-5}]
+
+-- Subquery inside a disjunction: the LEFT join is unconditional and matches
+-- <=1 row per outer row (group keys are a unique key), so outer multiplicity is
+-- preserved and the substituted value drives the OR correctly.
+SELECT o.id, o.total FROM o WHERE o.total < 0 OR o.total > (SELECT avg(c.amount) FROM c WHERE c.fk = o.k) ORDER BY o.id;
+→ [{"id":1,"total":8},{"id":4,"total":-5},{"id":5,"total":20}]
+
+-- Two scalar-agg subqueries in one predicate: one stacked LEFT join each.
+SELECT o.id, o.total FROM o WHERE o.total > (SELECT avg(c.amount) FROM c WHERE c.fk = o.k) AND (SELECT count(*) FROM c WHERE c.fk = o.k) >= 2 ORDER BY o.id;
+→ [{"id":1,"total":8}]
+
+-- EXISTS plus a scalar-agg comparison in the same WHERE: subquery-decorrelation
+-- turns EXISTS into a semi-join first, then this rule decorrelates the avg
+-- comparison over the already-rewritten source. Both fire; result stays correct.
+SELECT o.id, o.total FROM o WHERE EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AND o.total > (SELECT avg(c.amount) FROM c WHERE c.fk = o.k) ORDER BY o.id;
+→ [{"id":1,"total":8},{"id":5,"total":20}]
+
+-- Bail-but-correct: non-equi correlation (c.fk < o.k) cannot become a group key,
+-- so the subquery stays correlated. Result must still be right.
+--   avg(amount) where fk < k:  o1 {} NULL, o2 {10}=6, o3 {10,20}=6, o4 {} NULL, o5 {10,20}=6
+SELECT o.id, o.total FROM o WHERE o.total > (SELECT avg(c.amount) FROM c WHERE c.fk < o.k) ORDER BY o.id;
+→ [{"id":3,"total":100},{"id":5,"total":20}]
+
+-- Bail-but-correct: a non-aggregate LIMIT 1 subquery is not the aggregate root
+-- the rule requires, so it stays correlated. (ORDER BY makes the pick
+-- deterministic.)  min amount per k: o1 5, o2 4, o5 1; o3/o4 no rows → NULL.
+--   o1 8>5 T, o2 3>4 F, o5 20>1 T.
+SELECT o.id, o.total FROM o WHERE o.total > (SELECT c.amount FROM c WHERE c.fk = o.k ORDER BY c.amount LIMIT 1) ORDER BY o.id;
+→ [{"id":1,"total":8},{"id":5,"total":20}]
+
+-- Mixed: one decorrelatable (avg) and one bail (LIMIT 1) subquery in the SAME
+-- predicate. The avg becomes a grouped left join; the LIMIT-1 subquery stays
+-- correlated over the join source (its outer refs still resolve on the join's
+-- left side). Both must evaluate correctly together.
+--   avg/k: o1 6,o2 6,o3 NULL,o5 1 ;  min/k: o1 5,o2 4,o3 NULL,o5 1.
+--   o1 8>6 ∧ 8>5 T; o2 3>6 F; o3 100>NULL NULL; o4 NULL; o5 20>1 ∧ 20>1 T.
+SELECT o.id FROM o WHERE o.total > (SELECT avg(c.amount) FROM c WHERE c.fk = o.k) AND o.total > (SELECT c.amount FROM c WHERE c.fk = o.k ORDER BY c.amount LIMIT 1) ORDER BY o.id;
+→ [{"id":1},{"id":5}]
+
+-- HAVING setup: group `ord` by k, correlate a per-group cap table `lim` on the
+-- group key.
+CREATE TABLE ord (id INTEGER PRIMARY KEY, k INTEGER NULL, amt INTEGER);
+CREATE TABLE lim (id INTEGER PRIMARY KEY, gk INTEGER NULL, cap INTEGER);
+
+INSERT INTO ord VALUES (1,10,5),(2,10,7),(3,20,4),(4,20,2),(5,30,9);
+INSERT INTO lim VALUES (1,10,3),(2,10,6),(3,20,10);
+-- group sums: k=10 → 12, k=20 → 6, k=30 → 9
+
+-- HAVING comparison correlating to the group key (ord.k): decorrelates the same
+-- as a WHERE, the Filter's source being the group Aggregate.
+--   min(cap) where gk=k:  k=10 → 3, k=20 → 10, k=30 → NULL
+SELECT ord.k, sum(ord.amt) AS s FROM ord GROUP BY ord.k HAVING sum(ord.amt) > (SELECT min(lim.cap) FROM lim WHERE lim.gk = ord.k) ORDER BY ord.k;
+→ [{"k":10,"s":12}]
+
+-- HAVING with a correlated count empty-group: group k=30 has no lim rows →
+-- count 0 → survives the HAVING filter (empty-value marker in the Filter path).
+SELECT ord.k, sum(ord.amt) AS s FROM ord GROUP BY ord.k HAVING (SELECT count(*) FROM lim WHERE lim.gk = ord.k) = 0 ORDER BY ord.k;
+→ [{"k":30,"s":9}]
+
+-- HAVING correlating to the aggregate result itself (sum(ord.amt)): valid but
+-- unusual. Whether it decorrelates or bails, the result must be correct.
+--   count(*) where cap = sum:  k=10 sum12 → 0, k=20 sum6 → 1 (cap 6), k=30 sum9 → 0
+SELECT ord.k, sum(ord.amt) AS s FROM ord GROUP BY ord.k HAVING sum(ord.amt) > (SELECT count(*) FROM lim WHERE lim.cap = sum(ord.amt)) ORDER BY ord.k;
+→ [{"k":10,"s":12},{"k":20,"s":6},{"k":30,"s":9}]
+
+-- Two stacked scalar-agg subqueries in one HAVING predicate: one grouped left
+-- join each, over the group Aggregate as source (the anchor-agnostic stacking
+-- path, previously covered only for WHERE).
+--   min(cap)/k: 10→3,20→10,30→NULL ;  count/k: 10→2,20→1,30→0.
+--   k=10 12>3 ∧ 12>2 T; k=20 6>10 F; k=30 9>NULL NULL.
+SELECT ord.k, sum(ord.amt) AS s FROM ord GROUP BY ord.k HAVING sum(ord.amt) > (SELECT min(lim.cap) FROM lim WHERE lim.gk = ord.k) AND sum(ord.amt) > (SELECT count(*) FROM lim WHERE lim.gk = ord.k) ORDER BY ord.k;
+→ [{"k":10,"s":12}]

package/test/logic/07.7.2-scalar-agg-decorrelation-nested.sqllogic

@@ -0,0 +1,115 @@
+-- 07.7.2-scalar-agg-decorrelation-nested.sqllogic
+-- Scalar-aggregate subqueries nested inside other aggregate subqueries
+-- (parent → child → grandchild JSON trees) are decorrelated level by level:
+-- the Project-site rule (scalar-agg-decorrelation) rewrites the outer level,
+-- and the aggregate-argument site (scalar-agg-decorrelation-aggregate) then
+-- rewrites the subquery that lands inside the new grouped aggregate's
+-- argument. These tests pin the observable semantics of the fully set-based
+-- shapes and of the shapes that must stay (partially) correlated.
+
+-- Setup: the 3-table hierarchy from the motivating perf report — log entries
+-- → items on an entry (via a join table) → per-(entry, item) quantifier
+-- values (joined to their quantifier definitions).
+CREATE TABLE e (id INTEGER PRIMARY KEY, name TEXT);
+CREATE TABLE lei (entry_id INTEGER, item_id INTEGER, PRIMARY KEY (entry_id, item_id));
+CREATE TABLE items (id INTEGER PRIMARY KEY, label TEXT);
+CREATE TABLE qv (entry_id INTEGER, item_id INTEGER, quantifier_id INTEGER, value REAL, PRIMARY KEY (entry_id, item_id, quantifier_id));
+CREATE TABLE q (id INTEGER PRIMARY KEY, name TEXT);
+
+INSERT INTO e VALUES (1,'a'),(2,'b'),(3,'empty');
+INSERT INTO items VALUES (10,'i10'),(11,'i11'),(12,'i12');
+-- entry 3 has no items; item 11 (on entry 1) has no quantifier values
+INSERT INTO lei VALUES (1,10),(1,11),(2,12);
+INSERT INTO q VALUES (100,'qa'),(101,'qb');
+INSERT INTO qv VALUES (1,10,100,1.5),(1,10,101,2.5),(2,12,100,9.0);
+
+-- The motivating 2-level query: json_group_array(json_object(...)) at both
+-- levels, level-2 correlation spanning two ancestor levels (e.id and i.id).
+-- An item with no quantifier values gets NULL (json_group_array over a
+-- zero-row scalar-subquery group — same as the correlated baseline); an entry
+-- with no items gets NULL at level 1 and level 2 never evaluates.
+select e.id,
+  (select json_group_array(json_object(
+     'itemId', i.id,
+     'quantifiers', (
+        select json_group_array(json_object('id', q.id, 'value', qv.value))
+        from qv join q on q.id = qv.quantifier_id
+        where qv.entry_id = e.id and qv.item_id = i.id)))
+   from lei join items i on i.id = lei.item_id
+   where lei.entry_id = e.id) as items
+from e order by e.id;
+→ [{"id":1,"items":[{"itemId":10,"quantifiers":[{"id":100,"value":1.5},{"id":101,"value":2.5}]},{"itemId":11,"quantifiers":null}]},{"id":2,"items":[{"itemId":12,"quantifiers":[{"id":100,"value":9}]}]},{"id":3,"items":null}]
+
+-- Nested count inside sum: non-NULL empty value (count → 0) at level 2 needs
+-- the join-miss CASE marker below the level-1 aggregate; entry 3 (no items)
+-- sums over zero rows → NULL.
+select e.id,
+  (select sum((select count(*) from qv where qv.entry_id = e.id and qv.item_id = i.id))
+   from lei join items i on i.id = lei.item_id
+   where lei.entry_id = e.id) as total
+from e order by e.id;
+→ [{"id":1,"total":2},{"id":2,"total":1},{"id":3,"total":null}]
+
+-- Three levels of nesting: the rewrite converges level by level.
+CREATE TABLE tags (quantifier_id INTEGER, tag TEXT, PRIMARY KEY (quantifier_id, tag));
+INSERT INTO tags VALUES (100,'t1'),(100,'t2');
+select e.id,
+  (select json_group_array(json_object(
+     'itemId', i.id,
+     'quantifiers', (
+        select json_group_array(json_object('qid', qv.quantifier_id,
+          'tags', (select json_group_array(t.tag) from tags t where t.quantifier_id = qv.quantifier_id)))
+        from qv
+        where qv.entry_id = e.id and qv.item_id = i.id)))
+   from lei join items i on i.id = lei.item_id
+   where lei.entry_id = e.id) as items
+from e order by e.id;
+→ [{"id":1,"items":[{"itemId":10,"quantifiers":[{"qid":100,"tags":["t1","t2"]},{"qid":101,"tags":null}]},{"itemId":11,"quantifiers":null}]},{"id":2,"items":[{"itemId":12,"quantifiers":[{"qid":100,"tags":["t1","t2"]}]}]},{"id":3,"items":null}]
+
+-- DISTINCT aggregate at level 2: the at-most-one join adds no duplicate rows,
+-- so the distinct set is unchanged.
+select e.id,
+  (select json_group_array((select count(distinct qv.quantifier_id) from qv where qv.entry_id = e.id and qv.item_id = i.id))
+   from lei join items i on i.id = lei.item_id
+   where lei.entry_id = e.id) as d
+from e order by e.id;
+→ [{"id":1,"d":[2,0]},{"id":2,"d":[1]},{"id":3,"d":null}]
+
+-- Sibling subqueries inside one aggregate argument: each gets its own join.
+select lei.entry_id, json_group_array(
+   (select count(*) from qv where qv.entry_id = lei.entry_id and qv.item_id = lei.item_id)
+ + (select total(qv.value) from qv where qv.entry_id = lei.entry_id and qv.item_id = lei.item_id)) as j
+from lei group by lei.entry_id order by lei.entry_id;
+→ [{"entry_id":1,"j":[6,0]},{"entry_id":2,"j":[10]}]
+
+-- The aggregate-argument site also fires on a top-level (user-written)
+-- GROUP BY aggregate — not only on nested subqueries.
+select lei.entry_id, json_group_array((select count(*) from qv where qv.entry_id = lei.entry_id and qv.item_id = lei.item_id)) as j
+from lei group by lei.entry_id order by lei.entry_id;
+→ [{"entry_id":1,"j":[2,0]},{"entry_id":2,"j":[1]}]
+
+-- HAVING evaluates against the (attribute-id-preserved) aggregate output and
+-- is undisturbed by the join inserted below the aggregate.
+select lei.entry_id, sum((select count(*) from qv where qv.entry_id = lei.entry_id and qv.item_id = lei.item_id)) as s
+from lei group by lei.entry_id having count(*) > 1 order by lei.entry_id;
+→ [{"entry_id":1,"s":2}]
+
+-- Correlated aggregate subquery as a GROUP BY expression (pathological but
+-- supported: group-by expressions are per-source-row scalar trees too).
+select (select count(*) from qv where qv.entry_id = lei.entry_id) as g, count(*) as n
+from lei group by 1 order by g;
+→ [{"g":1,"n":1},{"g":2,"n":2}]
+
+-- Remap-bailed level 1: the NOCASE correlation cannot justify remapping
+-- en.name (referenced in the aggregate argument) to ln.ename, so level 1
+-- stays correlated — and both levels stay correct.
+CREATE TABLE en (name TEXT PRIMARY KEY COLLATE NOCASE);
+CREATE TABLE ln (ename TEXT COLLATE NOCASE, item_id INTEGER, PRIMARY KEY (ename, item_id));
+INSERT INTO en VALUES ('A'),('b');
+INSERT INTO ln VALUES ('a',10),('A',11),('B',12);
+select en.name,
+  (select json_group_array(json_object('n', en.name, 'item', ln.item_id,
+     'cnt', (select count(*) from qv where qv.entry_id = 1 and qv.item_id = ln.item_id)))
+   from ln where ln.ename = en.name) as j
+from en order by en.name;
+→ [{"name":"A","j":[{"n":"A","item":10,"cnt":2},{"n":"A","item":11,"cnt":0}]},{"name":"b","j":[{"n":"b","item":12,"cnt":0}]}]

package/test/logic/07.7.3-exists-in-select-decorrelation.sqllogic

@@ -0,0 +1,107 @@
+-- 07.7.3-exists-in-select-decorrelation.sqllogic
+-- Correlated EXISTS / NOT EXISTS / IN in the SELECT list are decorrelated into
+-- LEFT joins carrying an `exists right as` match flag (rule
+-- exists-in-select-decorrelation). Every outer row must survive with the match
+-- reported as a column — a semi/anti join cannot express that. These tests pin
+-- the observable semantics of the decorrelated shapes AND the shapes the rule
+-- must reject (which stay on the correlated per-row path).
+
+-- Setup. c has THREE rows with fk = 10 — the fan-out hazard: a plain left join
+-- would duplicate the outer row per match, so the rule must collapse the inner
+-- side to one row per correlation key.
+CREATE TABLE o (id INTEGER PRIMARY KEY, k INTEGER NULL, g INTEGER NULL);
+CREATE TABLE c (id INTEGER PRIMARY KEY, fk INTEGER NULL, g INTEGER NULL, v INTEGER NULL);
+INSERT INTO o VALUES (1, 10, 1), (2, 20, 1), (3, null, 2), (4, 30, 2);
+INSERT INTO c VALUES (1, 10, 1, 5), (2, 10, 1, 6), (3, 10, 2, null), (4, 20, 2, 7), (5, null, 1, 8), (6, null, 1, 20);
+
+-- EXISTS flag with inner fan-out (k=10 matches 3 inner rows): exactly one
+-- output row per outer row; NULL outer key and no-match rows report false
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":true},{"id":2,"f":true},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- NOT EXISTS: the NOT wrapper survives over the two-valued flag
+SELECT o.id, NOT EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":false},{"id":2,"f":false},{"id":3,"f":true},{"id":4,"f":true}]
+
+-- Residual inner-only predicate alongside the correlation
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k AND c.v > 6) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":false},{"id":2,"f":true},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- Composite (multi-conjunct) correlation
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k AND c.g = o.g) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":true},{"id":2,"f":false},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- Multiple EXISTS in one SELECT list: one stacked join per subquery, flags distinct
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS a, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k AND c.v > 6) AS b FROM o ORDER BY o.id;
+→ [{"id":1,"a":true,"b":false},{"id":2,"a":true,"b":true},{"id":3,"a":false,"b":false},{"id":4,"a":false,"b":false}]
+
+-- EXISTS in the SELECT list AND in WHERE of the same query: the WHERE one
+-- becomes a semi join (existing rule), the SELECT-list one a flag join
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k AND c.v > 6) AS f FROM o WHERE EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) ORDER BY o.id;
+→ [{"id":1,"f":false},{"id":2,"f":true}]
+
+-- EXISTS inside a CASE wrapper: only the inner node is substituted
+SELECT o.id, CASE WHEN EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) THEN 'y' ELSE 'n' END AS b FROM o ORDER BY o.id;
+→ [{"id":1,"b":"y"},{"id":2,"b":"y"},{"id":3,"b":"n"},{"id":4,"b":"n"}]
+
+-- SELECT * inner body (multi-column projection is irrelevant to EXISTS)
+SELECT o.id, EXISTS (SELECT * FROM c WHERE c.fk = o.k) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":true},{"id":2,"f":true},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- Mixed with a correlated scalar-aggregate subquery in the same list (both
+-- decorrelation rules fire on the same projection)
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS f, (SELECT count(*) FROM c WHERE c.fk = o.k) AS n FROM o ORDER BY o.id;
+→ [{"id":1,"f":true,"n":3},{"id":2,"f":true,"n":1},{"id":3,"f":false,"n":0},{"id":4,"f":false,"n":0}]
+
+-- Correlated IN in the projection, both comparison sides non-nullable (o.id and
+-- c.id are PKs): decorrelated; true / false / empty-inner-false all correct
+SELECT o.id, (o.id IN (SELECT c.id FROM c WHERE c.fk = o.k)) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":true},{"id":2,"f":false},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- NOT IN over the same non-nullable shape: NOT over the exact two-valued flag
+SELECT o.id, (o.id NOT IN (SELECT c.id FROM c WHERE c.fk = o.k)) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":false},{"id":2,"f":true},{"id":3,"f":true},{"id":4,"f":true}]
+
+-- Rejected shapes: these stay on the correlated per-row path and must keep
+-- today's (three-valued where applicable) semantics.
+
+-- IN with a NULLABLE inner column: must bail — a no-match against a set
+-- containing NULL yields NULL, not false (o.id 2: the only v=20 row has fk
+-- NULL, so `2 IN (NULL)` is NULL)
+SELECT o.id, (o.id IN (SELECT c.fk FROM c WHERE c.v = o.k)) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":false},{"id":2,"f":null},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- NOT IN with inner NULLs: NULL propagates through the NOT (per-row path)
+SELECT o.id, (o.id NOT IN (SELECT c.fk FROM c WHERE c.v = o.k)) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":true},{"id":2,"f":null},{"id":3,"f":true},{"id":4,"f":true}]
+
+-- Non-equi correlation: bail via the extraction gate; stays correlated but correct
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.v < o.k) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":true},{"id":2,"f":true},{"id":3,"f":false},{"id":4,"f":true}]
+
+-- Outer reference outside the equi-conjuncts (c.v = o.id + 4 is not a bare
+-- column equality): bail; per-row result preserved
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k AND c.v = o.id + 4) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":true},{"id":2,"f":false},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- Uncorrelated EXISTS: not this rule's shape (cached per-statement already)
+SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.v > 100) AS f FROM o ORDER BY o.id;
+→ [{"id":1,"f":false},{"id":2,"f":false},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- Shape invariance: the decorrelated projection feeds a derived table consumed
+-- by SELECT * — only the projected columns appear, no leaked join/flag columns
+SELECT * FROM (SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS f FROM o) sub ORDER BY sub.id;
+→ [{"id":1,"f":true},{"id":2,"f":true},{"id":3,"f":false},{"id":4,"f":false}]
+
+-- Flag consumed as a WHERE probe upstream (existence-flag recovery interaction):
+-- results stay exact under any downstream semi/anti re-shaping
+SELECT sub.id FROM (SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS f FROM o) sub WHERE sub.f ORDER BY sub.id;
+→ [{"id":1},{"id":2}]
+
+SELECT sub.id FROM (SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS f FROM o) sub WHERE NOT sub.f ORDER BY sub.id;
+→ [{"id":3},{"id":4}]
+
+-- Flag unused upstream (existence-flag pruning interaction): the outer query
+-- never reads f; row count and values unchanged
+SELECT sub.id FROM (SELECT o.id, EXISTS (SELECT 1 FROM c WHERE c.fk = o.k) AS f FROM o) sub ORDER BY sub.id;
+→ [{"id":1},{"id":2},{"id":3},{"id":4}]

package/test/logic/07.7.4-where-conjunct-ordering.sqllogic

@@ -0,0 +1,121 @@
+-- where-conjunct-ordering.sqllogic - WHERE conjunct cost ordering end-to-end
+-- Complements test/where-conjunct-ordering.spec.ts (which owns the evaluation
+-- counts and plan-shape assertions via a counting UDF). This file pins row-set
+-- parity: `rule-filter-conjunct-ordering` reorders a Filter's AND conjuncts
+-- cheapest-first, and that must NEVER change which rows a query returns — for
+-- both written orders of each query, NULL conjuncts, the `v <> 0` guard idiom,
+-- a HAVING conjunction, and the three-valued-logic truth table.
+
+-- 13 rows: k = (id-1) % 3, v = id except the last row's v = 0 (the guard-idiom
+-- divisor). k = 2 holds for ids {3,6,9,12}; v % 5 = 2 for ids {2,7,12}.
+create table t (id integer primary key, k integer, v integer);
+insert into t values
+  (1, 0, 1), (2, 1, 2), (3, 2, 3), (4, 0, 4), (5, 1, 5), (6, 2, 6),
+  (7, 0, 7), (8, 1, 8), (9, 2, 9), (10, 0, 10), (11, 1, 11), (12, 2, 12),
+  (13, 0, 0);
+
+-- =============================================================================
+-- Both written orders of a subquery + pure-arithmetic conjunction return the
+-- same rows (the subquery conjunct is reordered last; results must not move).
+-- =============================================================================
+
+select id from t where (select length('x')) = 1 and v % 5 = 2 order by id;
+→ [{"id":2},{"id":7},{"id":12}]
+
+select id from t where v % 5 = 2 and (select length('x')) = 1 order by id;
+→ [{"id":2},{"id":7},{"id":12}]
+
+select id from t where (select count(*) from t) = 13 and k = 2 and v % 5 = 2 order by id;
+→ [{"id":12}]
+
+select id from t where k = 2 and v % 5 = 2 and (select count(*) from t) = 13 order by id;
+→ [{"id":12}]
+
+-- =============================================================================
+-- NULL conjuncts: a Filter rejects on NULL exactly as on false, in either
+-- position, so both orders return zero rows.
+-- =============================================================================
+
+select id from t where null and k = 2;
+→ []
+
+select id from t where k = 2 and null;
+→ []
+
+-- =============================================================================
+-- Guard idiom: `v <> 0` protecting a division. Sound in either order (division
+-- by zero yields NULL, which the Filter rejects), and cost ordering keeps the
+-- simpler guard first anyway. Pinned so a future cost-model change cannot
+-- silently break it. 10 / v <= 10 holds for every v >= 1.
+-- =============================================================================
+
+select id from t where v <> 0 and 10 / v <= 10 order by id;
+→ [{"id":1},{"id":2},{"id":3},{"id":4},{"id":5},{"id":6},{"id":7},{"id":8},{"id":9},{"id":10},{"id":11},{"id":12}]
+
+select id from t where 10 / v <= 10 and v <> 0 order by id;
+→ [{"id":1},{"id":2},{"id":3},{"id":4},{"id":5},{"id":6},{"id":7},{"id":8},{"id":9},{"id":10},{"id":11},{"id":12}]
+
+-- =============================================================================
+-- HAVING conjunctions build FilterNodes too, so the rule applies there as well.
+-- k = 0 has 5 rows, k = 1 and k = 2 have 4 each.
+-- =============================================================================
+
+select k, count(*) as c from t group by k having count(*) >= 4 and k > 0 order by k;
+→ [{"k":1,"c":4},{"k":2,"c":4}]
+
+select k, count(*) as c from t group by k having k > 0 and count(*) >= 4 order by k;
+→ [{"k":1,"c":4},{"k":2,"c":4}]
+
+-- =============================================================================
+-- Three-valued logic under reordering: `a and b` vs `b and a` over every
+-- {true,false,null}² pair. A Filter keeps a row only when the conjunction is
+-- true, and AND is commutative under 3VL, so both orders keep exactly the rows
+-- where both operands are true.
+-- =============================================================================
+
+create table tv (id integer primary key, a integer null, b integer null);
+insert into tv values
+  (1, 1, 1), (2, 1, 0), (3, 1, null),
+  (4, 0, 1), (5, 0, 0), (6, 0, null),
+  (7, null, 1), (8, null, 0), (9, null, null);
+
+select id from tv where a and b order by id;
+→ [{"id":1}]
+
+select id from tv where b and a order by id;
+→ [{"id":1}]
+
+-- =============================================================================
+-- Selectivity-driven ordering (ANALYZEd table): within one cost tier the rule
+-- now runs the conjunct that statistics say rejects more rows per unit work
+-- first. `weak` has 2 distinct values, `strong` 50, so `strong in (2, 3)`
+-- (est. 0.04) sorts ahead of `weak = 1` (est. 0.5) despite the pricier IN list.
+-- Row-set parity for both written orders is what this file can pin; the plan
+-- order itself is asserted in test/where-conjunct-ordering.spec.ts.
+-- weak = id % 2, strong = id % 50 → the conjunction keeps ids {3, 53}.
+-- =============================================================================
+
+create table sel (id integer primary key, weak integer, strong integer);
+insert into sel values
+  (1, 1, 1), (2, 0, 2), (3, 1, 3), (4, 0, 4), (5, 1, 5), (6, 0, 6), (7, 1, 7), (8, 0, 8), (9, 1, 9), (10, 0, 10),
+  (11, 1, 11), (12, 0, 12), (13, 1, 13), (14, 0, 14), (15, 1, 15), (16, 0, 16), (17, 1, 17), (18, 0, 18), (19, 1, 19), (20, 0, 20),
+  (21, 1, 21), (22, 0, 22), (23, 1, 23), (24, 0, 24), (25, 1, 25), (26, 0, 26), (27, 1, 27), (28, 0, 28), (29, 1, 29), (30, 0, 30),
+  (31, 1, 31), (32, 0, 32), (33, 1, 33), (34, 0, 34), (35, 1, 35), (36, 0, 36), (37, 1, 37), (38, 0, 38), (39, 1, 39), (40, 0, 40),
+  (41, 1, 41), (42, 0, 42), (43, 1, 43), (44, 0, 44), (45, 1, 45), (46, 0, 46), (47, 1, 47), (48, 0, 48), (49, 1, 49), (50, 0, 0),
+  (51, 1, 1), (52, 0, 2), (53, 1, 3), (54, 0, 4), (55, 1, 5), (56, 0, 6), (57, 1, 7), (58, 0, 8), (59, 1, 9), (60, 0, 10),
+  (61, 1, 11), (62, 0, 12), (63, 1, 13), (64, 0, 14), (65, 1, 15), (66, 0, 16), (67, 1, 17), (68, 0, 18), (69, 1, 19), (70, 0, 20),
+  (71, 1, 21), (72, 0, 22), (73, 1, 23), (74, 0, 24), (75, 1, 25), (76, 0, 26), (77, 1, 27), (78, 0, 28), (79, 1, 29), (80, 0, 30),
+  (81, 1, 31), (82, 0, 32), (83, 1, 33), (84, 0, 34), (85, 1, 35), (86, 0, 36), (87, 1, 37), (88, 0, 38), (89, 1, 39), (90, 0, 40),
+  (91, 1, 41), (92, 0, 42), (93, 1, 43), (94, 0, 44), (95, 1, 45), (96, 0, 46), (97, 1, 47), (98, 0, 48), (99, 1, 49), (100, 0, 0);
+
+analyze sel;
+
+select id from sel where weak = 1 and strong in (2, 3) order by id;
+→ [{"id":3},{"id":53}]
+
+select id from sel where strong in (2, 3) and weak = 1 order by id;
+→ [{"id":3},{"id":53}]
+
+drop table sel;
+drop table tv;
+drop table t;