@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/07.7.5-filter-lost-under-index-order.sqllogic

@@ -0,0 +1,134 @@
+-- filter-lost-under-index-order.sqllogic - a WHERE conjunct must survive ORDER BY absorption
+--
+-- Regression guard for `bug-filter-conjunct-lost-under-index-order`. When an
+-- ORDER BY is satisfied by the table's own primary-key walk, `rule-grow-retrieve`
+-- absorbs the Sort and commits the Retrieve to an index-style access plan. From
+-- that point `Retrieve.source` is no longer read at physicalization — so a
+-- predicate that `rule-predicate-pushdown` writes into it is silently discarded
+-- and the query returns EVERY row. The sub-select conjunct is what forces the
+-- residual predicate above the Retrieve where pushdown can re-attack it.
+--
+-- Invariant pinned here: for each shape, the `order by` variants return the same
+-- row set as the same query with no `order by`.
+
+create table o (id integer primary key, flag integer);
+insert into o values (1, 1), (2, 1), (3, 0);
+
+-- =============================================================================
+-- Scalar sub-select conjunct + a column comparison the module does not handle.
+-- All three ordering variants must agree.
+-- =============================================================================
+
+select id from o where flag = 0 and (select max(id) from o o2) > 0;
+→ [{"id":3}]
+
+select id from o where flag = 0 and (select max(id) from o o2) > 0 order by id;
+→ [{"id":3}]
+
+select id from o where flag = 0 and (select max(id) from o o2) > 0 order by id desc;
+→ [{"id":3}]
+
+-- The filtered column in the select list: a different plan shape (the Project no
+-- longer prunes `flag`), same requirement.
+
+select id, flag from o where flag = 0 and (select max(id) from o o2) > 0;
+→ [{"id":3,"flag":0}]
+
+select id, flag from o where flag = 0 and (select max(id) from o o2) > 0 order by id;
+→ [{"id":3,"flag":0}]
+
+select id, flag from o where flag = 0 and (select max(id) from o o2) > 0 order by id desc;
+→ [{"id":3,"flag":0}]
+
+-- Written the other way round: the sub-select conjunct first.
+
+select id from o where (select max(id) from o o2) > 0 and flag = 0 order by id;
+→ [{"id":3}]
+
+-- =============================================================================
+-- EXISTS as the sub-select conjunct — same mechanism, different subquery node.
+-- =============================================================================
+
+select id from o where flag = 0 and exists (select 1 from o o2 where o2.id > 0);
+→ [{"id":3}]
+
+select id from o where flag = 0 and exists (select 1 from o o2 where o2.id > 0) order by id;
+→ [{"id":3}]
+
+select id from o where flag = 0 and exists (select 1 from o o2 where o2.id > 0) order by id desc;
+→ [{"id":3}]
+
+-- A conjunct that keeps more than one row, so a dropped predicate cannot be
+-- mistaken for a correct single-row answer.
+
+select id from o where flag = 1 and (select max(id) from o o2) > 0 order by id;
+→ [{"id":1},{"id":2}]
+
+select id from o where flag = 1 and (select max(id) from o o2) > 0 order by id desc;
+→ [{"id":2},{"id":1}]
+
+drop table o;
+
+-- =============================================================================
+-- Three-conjunct shape: two pure predicates plus a sub-select. This one loses
+-- the pushed conjunct even when the filtered column IS selected.
+-- k = (id-1) % 3, so 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);
+
+select id, k from t where k = 2 and v % 5 = 2 and (select count(*) from t t2) = 12;
+→ [{"id":12,"k":2}]
+
+select id, k from t where k = 2 and v % 5 = 2 and (select count(*) from t t2) = 12 order by id;
+→ [{"id":12,"k":2}]
+
+select id, k from t where k = 2 and v % 5 = 2 and (select count(*) from t t2) = 12 order by id desc;
+→ [{"id":12,"k":2}]
+
+select id from t where (select count(*) from t t2) = 12 and k = 2 and v % 5 = 2 order by id;
+→ [{"id":12}]
+
+-- Only the pure conjunct that the module cannot claim, plus the sub-select:
+-- multiple surviving rows, ascending order absorbed by the primary-key walk.
+
+select id from t where k = 2 and (select count(*) from t t2) = 12 order by id;
+→ [{"id":3},{"id":6},{"id":9},{"id":12}]
+
+select id from t where k = 2 and (select count(*) from t t2) = 12 order by id desc;
+→ [{"id":12},{"id":9},{"id":6},{"id":3}]
+
+-- LIMIT on top of the absorbed order. LimitOffset is the other operation
+-- grow-retrieve can translate into an index-style context, so it re-probes the
+-- already-committed access plan; the conjunct must survive that too.
+
+select id from t where k = 2 and (select count(*) from t t2) = 12 order by id limit 2;
+→ [{"id":3},{"id":6}]
+
+select id from t where k = 2 and (select count(*) from t t2) = 12 order by id limit 2 offset 1;
+→ [{"id":6},{"id":9}]
+
+drop table t;
+
+-- =============================================================================
+-- The mutation planner walks the same Retrieve/access-path rules, so a dropped
+-- conjunct there deletes or updates rows the WHERE clause excluded.
+-- =============================================================================
+
+create table m (id integer primary key, flag integer);
+insert into m values (1, 1), (2, 1), (3, 0), (4, 0);
+
+delete from m where flag = 0 and (select max(id) from m m2) > 0;
+
+select id, flag from m order by id;
+→ [{"id":1,"flag":1},{"id":2,"flag":1}]
+
+update m set flag = 9 where flag = 1 and (select max(id) from m m2) > 0;
+
+select id, flag from m order by id;
+→ [{"id":1,"flag":9},{"id":2,"flag":9}]
+
+drop table m;

package/test/logic/07.7.6-correlated-predicate-scope.sqllogic

@@ -0,0 +1,178 @@
+-- 07.7.6-correlated-predicate-scope.sqllogic - a subquery's predicate must not
+-- constrain the outer relation
+--
+-- Regression guard for `bug-correlated-predicate-hoisted-onto-outer`. When an
+-- ORDER BY is satisfied by the outer table's primary-key walk, `rule-grow-retrieve`
+-- takes the `trySortAbsorbViaIndexOrdering` path, which sweeps constraints out of a
+-- whole subtree rather than out of one Filter's own predicate. A correlated subquery
+-- body hangs off a scalar predicate, so that subtree contains the *inner* comparison
+-- (`t.s = a.i`). Attributing it to the outer table `a` turned it into an unhandled
+-- constraint, then into a residual predicate, and finally into a Filter reading
+-- column `s` placed over the scan of `a` — which has no such column. The failure
+-- surfaced as "No row context found for column s".
+--
+-- The correlated conjunct only survives inside the subquery when the comparison is
+-- cross-type: with matching types (`t.id = a.i`) the decorrelation rule rewrites the
+-- EXISTS into a semi join and there is nothing left inside a subquery to mis-attribute.
+-- Both shapes are covered below so the decorrelating path stays exercised too.
+--
+-- Invariant pinned here (OPT-025): for each shape, the `order by` variants return the
+-- same row set as the same query with no `order by`.
+
+create table a (id integer primary key, i integer);
+create table t (id integer primary key, s text);
+insert into a values (1, 1), (2, 2), (3, 3);
+insert into t values (1, '1'), (2, '2');
+
+-- =============================================================================
+-- EXISTS with a cross-type correlated comparison — the original repro.
+-- =============================================================================
+
+select a.id from a where exists (select 1 from t where t.s = a.i);
+→ [{"id":1},{"id":2}]
+
+select a.id from a where exists (select 1 from t where t.s = a.i) order by a.id;
+→ [{"id":1},{"id":2}]
+
+select a.id from a where exists (select 1 from t where t.s = a.i) order by a.id desc;
+→ [{"id":2},{"id":1}]
+
+-- The correlated column in the select list: the Project no longer prunes `i`,
+-- a different plan shape with the same requirement.
+
+select a.id, a.i from a where exists (select 1 from t where t.s = a.i) order by a.id;
+→ [{"id":1,"i":1},{"id":2,"i":2}]
+
+-- Written with the operands the other way round.
+
+select a.id from a where exists (select 1 from t where a.i = t.s) order by a.id;
+→ [{"id":1},{"id":2}]
+
+-- =============================================================================
+-- NOT EXISTS over the same shape. Hoisting the inner predicate onto the outer
+-- scan here yields a WRONG ANSWER rather than an error, so a row-set check is
+-- the only thing that catches it.
+-- =============================================================================
+
+select a.id from a where not exists (select 1 from t where t.s = a.i);
+→ [{"id":3}]
+
+select a.id from a where not exists (select 1 from t where t.s = a.i) order by a.id;
+→ [{"id":3}]
+
+select a.id from a where not exists (select 1 from t where t.s = a.i) order by a.id desc;
+→ [{"id":3}]
+
+-- =============================================================================
+-- IN over a correlated subquery whose inner predicate is cross-type.
+-- =============================================================================
+
+select a.id from a where a.i in (select t.id from t where t.s = a.i);
+→ [{"id":1},{"id":2}]
+
+select a.id from a where a.i in (select t.id from t where t.s = a.i) order by a.id;
+→ [{"id":1},{"id":2}]
+
+select a.id from a where a.i in (select t.id from t where t.s = a.i) order by a.id desc;
+→ [{"id":2},{"id":1}]
+
+-- =============================================================================
+-- Same-type correlated predicate: the decorrelation rule turns this into a semi
+-- join, so nothing is left inside a subquery. Kept so that path stays covered.
+-- =============================================================================
+
+select a.id from a where exists (select 1 from t where t.id = a.i);
+→ [{"id":1},{"id":2}]
+
+select a.id from a where exists (select 1 from t where t.id = a.i) order by a.id;
+→ [{"id":1},{"id":2}]
+
+select a.id from a where exists (select 1 from t where t.id = a.i) order by a.id desc;
+→ [{"id":2},{"id":1}]
+
+select a.id from a where not exists (select 1 from t where t.id = a.i) order by a.id;
+→ [{"id":3}]
+
+-- =============================================================================
+-- An outer conjunct alongside the correlated subquery: the outer predicate is
+-- genuinely a constraint on `a` and must still be applied, while the inner one
+-- must still be ignored.
+-- =============================================================================
+
+select a.id from a where a.id > 1 and exists (select 1 from t where t.s = a.i) order by a.id;
+→ [{"id":2}]
+
+select a.id from a where a.id > 1 and not exists (select 1 from t where t.s = a.i) order by a.id;
+→ [{"id":3}]
+
+-- =============================================================================
+-- An OUTER column compared to a CONSTANT inside the subquery body. This is the
+-- shape the `correlated` guard in computeCoveredKeysForConstraints cannot catch:
+-- the value side is a literal, so the constraint looks like an ordinary covering
+-- equality on `a`. Only the scope gate keeps it inside the subquery. Under
+-- NOT EXISTS the hoisted copy silently drops every row.
+-- =============================================================================
+
+select a.id from a where not exists (select 1 from t where a.i = 2);
+→ [{"id":1},{"id":3}]
+
+select a.id from a where not exists (select 1 from t where a.i = 2) order by a.id;
+→ [{"id":1},{"id":3}]
+
+select a.id from a where not exists (select 1 from t where a.i = 2) order by a.id desc;
+→ [{"id":3},{"id":1}]
+
+select a.id from a where exists (select 1 from t where a.i = 2) order by a.id;
+→ [{"id":2}]
+
+-- Mixed with a genuinely correlated conjunct, so the subquery cannot be reduced
+-- to an outer-only test.
+
+select a.id from a where not exists (select 1 from t where t.s = a.i and a.i = 2) order by a.id;
+→ [{"id":1},{"id":3}]
+
+select a.id from a where exists (select 1 from t where t.s = a.i and a.i = 2) order by a.id;
+→ [{"id":2}]
+
+-- =============================================================================
+-- A self-referencing subquery over the SAME table as the outer relation. The
+-- inner scan is a distinct TableReferenceNode with its own attribute ids, so
+-- `a2.id = 2` never matched the outer instance even before the scope gate — these
+-- pass pre-fix. Kept as cheap coverage that the gate did not break the self-
+-- reference shape, not as a regression guard.
+-- =============================================================================
+
+select a.id from a where exists (select 1 from a a2 where a2.id = 2) order by a.id;
+→ [{"id":1},{"id":2},{"id":3}]
+
+select a.id from a where not exists (select 1 from a a2 where a2.id = 99) order by a.id;
+→ [{"id":1},{"id":2},{"id":3}]
+
+select a.id from a where exists (select 1 from a a2 where a2.id = a.i + 1) order by a.id;
+→ [{"id":1},{"id":2}]
+
+drop table a;
+drop table t;
+
+-- =============================================================================
+-- The mutation planner walks the same Retrieve/access-path rules, so the same
+-- mis-attribution there would delete or update the wrong rows.
+-- =============================================================================
+
+create table m (id integer primary key, i integer);
+create table n (id integer primary key, s text);
+insert into m values (1, 1), (2, 2), (3, 3);
+insert into n values (1, '1'), (2, '2');
+
+delete from m where not exists (select 1 from n where n.s = m.i);
+
+select id from m order by id;
+→ [{"id":1},{"id":2}]
+
+update m set i = 9 where exists (select 1 from n where n.s = m.i and n.id = 1);
+
+select id, i from m order by id;
+→ [{"id":1,"i":9},{"id":2,"i":2}]
+
+drop table m;
+drop table n;

package/test/logic/07.7.7-join-source-scope-shadowing.sqllogic

@@ -0,0 +1,137 @@
+-- 07.7.7-join-source-scope-shadowing.sqllogic - an inner join's own sources must
+-- shadow a same-named source in the enclosing query
+--
+-- Second symptom of `bug-cte-reference-as-second-join-source-fails-at-runtime`, with no
+-- CTE involved and — worse — no error: it silently returned wrong rows.
+--
+-- A join combines its two peer source scopes with MultiScope (first match wins). Each
+-- source scope used to fall back to the *enclosing* query's scope, so when MultiScope
+-- asked the LEFT peer about a name the left peer did not own, it forwarded the question
+-- outward and answered from there instead of letting the RIGHT peer answer. When the
+-- right peer's alias also names an outer source, the inner reference bound to the OUTER
+-- one — turning an uncorrelated subquery into a correlated one.
+--
+-- Fix: a FROM source's scope holds only its own columns; the enclosing-query fallback is
+-- composed once by the consumer (ShadowScope), after both peers have been consulted.
+--
+-- Invariant pinned here: the subquery below is uncorrelated (its `x` is its own `t1`), so
+-- `n` is the same constant on every outer row. Pre-fix it returned 3, 3, 0.
+--
+-- The second half of the file pins the other side of the same invariant: peers-first is
+-- not peers-only. An ON condition must still reach the enclosing query for a correlated
+-- column or a bind parameter — the fallback moved one level later, it did not go away.
+
+create table t1 (id integer primary key, v integer);
+insert into t1 values (1, 10), (2, 20), (3, 30);
+
+create table t2 (id integer primary key, v integer);
+insert into t2 values (1, 100), (2, 200);
+
+-- =============================================================================
+-- Inner join's RIGHT peer aliased the same as an outer source. `x.id` inside the
+-- subquery must be the inner `t1 as x`, giving 2 matches on every outer row.
+-- =============================================================================
+
+select x.id, (select count(*) from t2 join t1 as x on x.id = t2.id) as n
+from t1 as x order by x.id;
+→ [{"id":1,"n":2},{"id":2,"n":2},{"id":3,"n":2}]
+
+-- Operand-swapped condition — `x.id` is looked up second rather than first.
+
+select x.id, (select count(*) from t2 join t1 as x on t2.id = x.id) as n
+from t1 as x order by x.id;
+→ [{"id":1,"n":2},{"id":2,"n":2},{"id":3,"n":2}]
+
+-- Non-key join column, so the join is not answered by a primary-key seek.
+
+select x.id, (select count(*) from t2 join t1 as x on x.v = t2.v) as n
+from t1 as x order by x.id;
+→ [{"id":1,"n":0},{"id":2,"n":0},{"id":3,"n":0}]
+
+-- =============================================================================
+-- Same shape with the inner LEFT peer an inline subquery source, which builds its
+-- scope on a separate code path (the `subquerySource` branch of buildFrom).
+-- =============================================================================
+
+select x.id, (select count(*) from (select id from t2) s join t1 as x on x.id = s.id) as n
+from t1 as x order by x.id;
+→ [{"id":1,"n":2},{"id":2,"n":2},{"id":3,"n":2}]
+
+-- The inline subquery on the RIGHT instead: the outer `s` must not capture `s.id`.
+
+select s.id, (select count(*) from t1 as x join (select id from t2) s on x.id = s.id) as n
+from t1 as s order by s.id;
+→ [{"id":1,"n":2},{"id":2,"n":2},{"id":3,"n":2}]
+
+-- =============================================================================
+-- A genuinely correlated subquery over the same alias names still correlates —
+-- the fix must not sever the enclosing-scope fallback, only reorder it after the
+-- join's own peers. `outer_t.id` is not a name either inner peer owns.
+-- =============================================================================
+
+select outer_t.id,
+       (select count(*) from t2 join t1 as x on x.id = t2.id where x.id = outer_t.id) as n
+from t1 as outer_t order by outer_t.id;
+→ [{"id":1,"n":1},{"id":2,"n":1},{"id":3,"n":0}]
+
+-- LATERAL still sees the left peer's columns from the right peer's body.
+
+select l.id, r.doubled from t1 as l
+cross join lateral (select l.v * 2 as doubled) as r
+order by l.id;
+→ [{"id":1,"doubled":20},{"id":2,"doubled":40},{"id":3,"doubled":60}]
+
+-- =============================================================================
+-- Reaching PAST both peers from an ON condition. Own-only peer scopes mean the
+-- MultiScope of the two peers answers "no" for everything the join does not own,
+-- so the ON condition's own context has to carry the enclosing-query fallback
+-- itself (ShadowScope([MultiScope([left, right]), outerScope]) in buildJoin).
+-- Without it nothing outside the join resolves in an ON clause at all.
+-- =============================================================================
+
+-- Qualified correlated outer column.
+
+select o.id, (select count(*) from t2 join t1 as x on x.id = t2.id and x.id = o.id) as n
+from t1 as o order by o.id;
+→ [{"id":1,"n":1},{"id":2,"n":1},{"id":3,"n":0}]
+
+-- Unqualified correlated outer column, owned by neither peer. When both peers
+-- chained to the enclosing scope, BOTH answered with the same outer symbol and
+-- MultiScope called it "ambiguous column name: ov".
+
+select o.id, (select count(*) from t2 join t1 as x on x.id = t2.id and x.v = ov) as n
+from (select id, v as ov from t1) as o order by o.id;
+→ [{"id":1,"n":1},{"id":2,"n":1},{"id":3,"n":0}]
+
+-- A bind parameter in an ON condition — resolved by the ParameterScope in the
+-- enclosing chain, not by either peer. Positional order still counts the ON
+-- clause's `?` before the WHERE clause's.
+
+-- params: [2, 30]
+select x.id from t2 join t1 as x on x.id = t2.id and t2.id = ? where x.v <> ?
+order by x.id;
+→ [{"id":2}]
+
+-- A scalar subquery inside an ON condition, correlated to the join's own LEFT peer.
+
+select t2.id as a, x.id as b from t2
+join t1 as x on x.id = (select max(t1b.id) from t1 as t1b where t1b.id = t2.id)
+order by t2.id;
+→ [{"a":1,"b":1},{"a":2,"b":2}]
+
+-- Three-way join: the outer join's ON reaches past a peer that is itself a join.
+
+select o.id, (select count(*) from t2 join t1 as x on x.id = t2.id
+              join t1 as y on y.id = x.id and y.id = o.id) as n
+from t1 as o order by o.id;
+→ [{"id":1,"n":1},{"id":2,"n":1},{"id":3,"n":0}]
+
+-- Ambiguity between the two peers is still ambiguity: the enclosing fallback sits
+-- BEHIND the MultiScope, so it must not answer after MultiScope has said "ambiguous".
+-- `v` is owned by both peers here, and also by the enclosing `o`.
+
+select o.id, (select count(*) from t1 join t2 on v = 100) as n from t1 as o;
+-- error: ambiguous column name: v
+
+drop table t2;
+drop table t1;

package/test/logic/07.7.8-correlated-ref-to-computed-column.sqllogic

@@ -0,0 +1,165 @@
+-- 07.7.8-correlated-ref-to-computed-column.sqllogic - a correlated sub-query may
+-- reference a column its enclosing query COMPUTES
+--
+-- Regression guard for `bug-correlated-subquery-cannot-read-outer-computed-column`.
+-- Two predicate-pushdown rules decide whether a Filter may slide below the node that
+-- computes a column, and both used to answer by walking the predicate's SCALAR tree
+-- only, stopping at any relational child. A correlated reference inside an `exists` /
+-- `in` / scalar-sub-query operand lives in exactly that relational subtree, so neither
+-- rule saw it: the dependency set came back empty, the push went ahead, and the
+-- reference landed BELOW the node defining the attribute it reads. The failure
+-- surfaced as "No row context found for column <c>".
+--
+-- Both rules now collect dependencies across sub-query operands as well (see
+-- src/planner/analysis/predicate-dependencies.ts), so the Filter stays put.
+--
+-- Sections:
+--   1. Filter vs a Project that computes the column (rule-predicate-pushdown)
+--   2. HAVING conjunct vs an aggregate (rule-aggregate-predicate-pushdown)
+-- Each section covers the shapes that used to fail AND the shapes that already
+-- worked — the fix must not degrade into a blanket refusal to push.
+--
+-- Plan-shape guards for the same statements live in
+-- test/optimizer/predicate-pushdown.spec.ts and
+-- test/optimizer/rule-aggregate-predicate-pushdown.spec.ts.
+
+-- =============================================================================
+-- 1. Correlated reference to a computed projection column.
+--
+-- `d` is minted by the sub-select's Project. `side` has exactly one row, so
+-- `exists (select 1 from side where <cond on d>)` is just `<cond on d>` evaluated
+-- once per outer row — the row set discriminates on the value of `d`.
+-- =============================================================================
+
+create table gt (id integer primary key, x integer);
+create table side (tag text primary key);
+insert into gt values (1, 10), (2, 20), (3, 0), (4, -5);
+insert into side values ('one');
+
+-- The original repro: EXISTS body reads the computed `d`.
+
+select id from (select id, x * 2 as d from gt) t where exists (select 1 from side where t.d > 0);
+→ [{"id":1},{"id":2}]
+
+select id from (select id, x * 2 as d from gt) t where exists (select 1 from side where t.d > 0) order by id desc;
+→ [{"id":2},{"id":1}]
+
+-- The scalar-sub-query form of the same thing: `max(t.d)` over `side`'s single row
+-- is `t.d` itself.
+
+select id from (select id, x * 2 as d from gt) t where (select max(t.d) from side) > 0;
+→ [{"id":1},{"id":2}]
+
+-- NOT EXISTS over the same shape — the complement, so a silently-empty or
+-- silently-full result set is caught too.
+
+select id from (select id, x * 2 as d from gt) t where not exists (select 1 from side where t.d > 0);
+→ [{"id":3},{"id":4}]
+
+-- The IN form: the correlated operand hangs off an `InNode`, which reports its own
+-- node type and exposes the relation only through `getChildren()`. The collector
+-- recognizes the relational child structurally, so no per-node-type list can rot.
+
+select id from (select id, x * 2 as d from gt) t where 1 in (select 1 from side where t.d > 0);
+→ [{"id":1},{"id":2}]
+
+-- Correlation buried two levels down: the operand's WHOLE subtree is scanned for
+-- outward references, not merely its top level.
+
+select id from (select id, x * 2 as d from gt) t
+	where exists (select 1 from side where exists (select 1 from side s2 where t.d > 0));
+→ [{"id":1},{"id":2}]
+
+-- Shapes that already worked and must keep working.
+
+select id from (select id, x from gt) t where exists (select 1 from side where t.x > 0);
+→ [{"id":1},{"id":2}]
+
+select id from (select id, x * 2 as d from gt) t where t.d in (select 20 union select 40);
+→ [{"id":1},{"id":2}]
+
+select id from (select id, x * 2 as d from gt) t where t.d > 0;
+→ [{"id":1},{"id":2}]
+
+-- The discriminating pair for "not a blanket refusal": the same Project computes
+-- `d` and passes `x` through. Correlating on `x` is still pushable (it exists below
+-- the Project); correlating on `d` is not. Both must return the same rows here.
+
+select id, d from (select id, x, x * 2 as d from gt) t where exists (select 1 from side where t.x > 0);
+→ [{"id":1,"d":20},{"id":2,"d":40}]
+
+select id, d from (select id, x, x * 2 as d from gt) t where exists (select 1 from side where t.d > 0);
+→ [{"id":1,"d":20},{"id":2,"d":40}]
+
+drop table gt;
+drop table side;
+
+-- =============================================================================
+-- 2. Correlated reference inside a HAVING conjunct.
+--
+-- `splitConjuncts` cannot break an `or` (or a `case`) apart, so one conjunct can
+-- mix a top-level reference to a pushable GROUP BY column with a correlated
+-- sub-query. Pushing it below the aggregate strands the correlated reference.
+--
+-- Groups: g=-1 (4 rows), g=0 (1 row), g=1 (2 rows), g=2 (1 row).
+-- `side` holds 1, 2, 3.
+-- =============================================================================
+
+create table t (id integer primary key, g integer, v integer);
+create table side (n integer primary key);
+insert into t values (1, 1, 10), (2, 1, 20), (3, 2, 30), (4, 0, 40),
+	(5, -1, 50), (6, -1, 60), (7, -1, 70), (8, -1, 80);
+insert into side values (1), (2), (3);
+
+-- Correlated on the GROUP BY column. g=-1 and g=0 fail both halves of the `or`.
+
+select g, count(*) as c from t group by g
+	having g > 1 or exists (select 1 from side where side.n = g) order by g;
+→ [{"g":1,"c":2},{"g":2,"c":1}]
+
+-- Correlated on the AGGREGATE output. g=-1 has 4 rows and 4 is not in `side`.
+
+select g, count(*) as c from t group by g
+	having g > 1 or exists (select 1 from side where side.n = count(*)) order by g;
+→ [{"g":0,"c":1},{"g":1,"c":2},{"g":2,"c":1}]
+
+-- The `case` form: one conjunct, correlation buried in a WHEN.
+
+select g, count(*) as c from t group by g
+	having (case when exists (select 1 from side where side.n = g) then g else 0 end) > 0 order by g;
+→ [{"g":1,"c":2},{"g":2,"c":1}]
+
+-- Shapes that already worked and must keep working.
+
+select g, count(*) as c from t group by g having g > 0 order by g;
+→ [{"g":1,"c":2},{"g":2,"c":1}]
+
+select g, count(*) as c from t group by g
+	having exists (select 1 from side where side.n = g) order by g;
+→ [{"g":1,"c":2},{"g":2,"c":1}]
+
+-- `and` splits into two conjuncts: `g > 0` pushes on its own and the correlated
+-- half stays above, where decorrelation turns it into a hash join.
+
+select g, count(*) as c from t group by g
+	having g > 0 and (select max(side.n) from side where side.n = g) is not null order by g;
+→ [{"g":1,"c":2},{"g":2,"c":1}]
+
+-- An UNCORRELATED sub-query alongside `g > 0`. `and` splits the two apart, so each
+-- half is judged on its own and the `g > 0` half still has to behave.
+
+select g, count(*) as c from t group by g
+	having g > 0 and exists (select 1 from side where side.n = 1) order by g;
+→ [{"g":1,"c":2},{"g":2,"c":1}]
+
+-- The same uncorrelated sub-query joined by `or`, so it CANNOT be split apart: one
+-- conjunct that both names a pushable GROUP BY column and carries a sub-query. The
+-- refusal above is about the correlation, not about carrying a sub-query, so this one
+-- must still push. `side` holds 1, so the `exists` is true and every group survives.
+
+select g, count(*) as c from t group by g
+	having g > 0 or exists (select 1 from side where side.n = 1) order by g;
+→ [{"g":-1,"c":4},{"g":0,"c":1},{"g":1,"c":2},{"g":2,"c":1}]
+
+drop table t;
+drop table side;