@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/47.4-upsert-conflict-target-affinity.sqllogic

@@ -0,0 +1,59 @@
+-- ON CONFLICT (cols) DO UPDATE / DO NOTHING must match an AFFINITY-coerced
+-- conflict: a proposed value of a different storage class that the target
+-- column's affinity coerces onto the stored key (e.g. TEXT '1' inserted into an
+-- INTEGER key holding 1). matchUpsertClause applies the column's affinity to the
+-- proposed value before comparing, so the conflict routes to the UPSERT arm
+-- instead of aborting. Ticket bug-upsert-conflict-target-collation-match.
+--
+-- Runs in BOTH memory and store mode. The isolation overlay
+-- (createIsolatedStoreModule, the store-mode harness) coerces the proposed row
+-- to the declared column types before probing for a conflict, same as the
+-- plain store and in-memory engine (bug-store-isolation-upsert-affinity-coerced-pk),
+-- so a cross-storage-class proposed PK value (e.g. TEXT '1' into an INTEGER key
+-- holding 1) matches the stored key instead of shadowing it with a fresh row.
+-- The collation-variant (same-storage-class) corners of this fix run in BOTH
+-- modes in the sibling file 47.3-upsert-conflict-target-collation.sqllogic.
+
+-- ===================================
+-- 1. Affinity coercion — proposed TEXT '1' into an INTEGER PK holding 1.
+--    The proposed value reaches the match pre-affinity-coercion; applying the
+--    column's INTEGER affinity turns '1' into 1, matching the stored key, so the
+--    existing row's DO UPDATE runs (n = 100 + 1).
+-- ===================================
+
+create table aff_pk (id integer primary key, n integer);
+insert into aff_pk values (1, 100);
+
+insert into aff_pk values ('1', 0) on conflict (id) do update set n = n + 1;
+select id, n, typeof(id) as t from aff_pk order by id;
+→ [{"id":1,"n":101,"t":"integer"}]
+
+drop table aff_pk;
+
+-- ===================================
+-- 2. Affinity coercion, DO NOTHING arm — the coerced conflict is SKIPPED, not
+--    aborted, and the existing row is left intact.
+-- ===================================
+
+create table aff_pk2 (id integer primary key, n integer);
+insert into aff_pk2 values (1, 100);
+
+insert into aff_pk2 values ('1', 999) on conflict (id) do nothing;
+select id, n from aff_pk2 order by id;
+→ [{"id":1,"n":100}]
+
+drop table aff_pk2;
+
+-- ===================================
+-- 3. Affinity coercion on a UNIQUE constraint (not the PK): TEXT '7' collides
+--    with a stored INTEGER 7 under the column's INTEGER affinity.
+-- ===================================
+
+create table aff_uc (id integer primary key, code integer unique, hits integer);
+insert into aff_uc values (1, 7, 1);
+
+insert into aff_uc values (2, '7', 0) on conflict (code) do update set hits = hits + 1;
+select id, code, hits from aff_uc order by id;
+→ [{"id":1,"code":7,"hits":2}]
+
+drop table aff_uc;

package/test/logic/47.5-upsert-do-update-constraints.sqllogic

@@ -0,0 +1,440 @@
+-- An INSERT's `on conflict ... do update` arm composes the row it writes inside
+-- the DML executor and hands it straight to the storage layer, so that row never
+-- passes through the statement's ConstraintCheckNode (which is INSERT-shaped and
+-- only ever sees the PROPOSED insert row). Before the fix the arm could therefore
+-- store a row that broke a CHECK, a NOT NULL, or a foreign key — one the equivalent
+-- plain `UPDATE` refuses.
+--
+-- The contract this file pins: the DO UPDATE arm validates the composed row under
+-- UPDATE-scoped constraints, identically to the equivalent plain `UPDATE`, and the
+-- per-constraint `on conflict <action>` defaults apply to a violation raised there.
+-- Every violating case asserts the error AND then selects to prove nothing was
+-- written. Ticket bug-upsert-do-update-skips-constraint-checks.
+--
+-- Not a case here: `insert or ignore ... on conflict ... do update`. The parser
+-- rejects that combination outright ("Cannot use both 'INSERT OR ...' and
+-- 'ON CONFLICT' in the same statement", covered in 47-upsert.sqllogic). The
+-- per-constraint `on conflict <action>` defaults below carry that semantics.
+
+-- ===================================
+-- 1. Row-level CHECK: the composed row is refused, and the message matches what
+--    the plain UPDATE of the same row produces.
+-- ===================================
+
+create table ck_row (a integer primary key, b integer, check (b < 10));
+insert into ck_row values (1, 1);
+
+insert into ck_row values (1, 2) on conflict (a) do update set b = 99;
+-- error: CHECK constraint failed: _check_0 (b < 10)
+
+-- nothing was written — not the proposed row, not the composed one.
+select a, b from ck_row;
+→ [{"a":1,"b":1}]
+
+-- the plain UPDATE spelling of the same write, for message parity.
+update ck_row set b = 99 where a = 1;
+-- error: CHECK constraint failed: _check_0 (b < 10)
+
+-- a satisfying DO UPDATE still succeeds — no over-rejection.
+insert into ck_row values (1, 2) on conflict (a) do update set b = 5;
+select a, b from ck_row;
+→ [{"a":1,"b":5}]
+
+drop table ck_row;
+
+-- ===================================
+-- 2. Column-level CHECK — attributed to the column's generated constraint name,
+--    same as the plain UPDATE.
+-- ===================================
+
+create table ck_col (a integer primary key, b integer check (b < 10));
+insert into ck_col values (1, 1);
+
+insert into ck_col values (1, 2) on conflict (a) do update set b = 99;
+-- error: CHECK constraint failed: _check_b (b < 10)
+
+select a, b from ck_col;
+→ [{"a":1,"b":1}]
+
+update ck_col set b = 99 where a = 1;
+-- error: CHECK constraint failed: _check_b (b < 10)
+
+drop table ck_col;
+
+-- ===================================
+-- 3. NOT NULL on the composed row.
+-- ===================================
+
+create table nn_t (a integer primary key, b integer not null);
+insert into nn_t values (1, 1);
+
+insert into nn_t values (1, 2) on conflict (a) do update set b = null;
+-- error: NOT NULL constraint failed: nn_t.b
+
+select a, b from nn_t;
+→ [{"a":1,"b":1}]
+
+update nn_t set b = null where a = 1;
+-- error: NOT NULL constraint failed: nn_t.b
+
+drop table nn_t;
+
+-- ===================================
+-- 4. A clause WHERE that skips the row short-circuits before any validation: no
+--    error is raised for the (violating) row it would have composed, and nothing
+--    is written.
+-- ===================================
+
+create table wh_t (a integer primary key, b integer, check (b < 10));
+insert into wh_t values (1, 1);
+
+insert into wh_t values (1, 2) on conflict (a) do update set b = 99 where false;
+select a, b from wh_t;
+→ [{"a":1,"b":1}]
+
+drop table wh_t;
+
+-- ===================================
+-- 5. DO NOTHING writes nothing and gains no validation.
+-- ===================================
+
+create table dn_t (a integer primary key, b integer, check (b < 10));
+insert into dn_t values (1, 1);
+
+insert into dn_t values (1, 2) on conflict (a) do nothing;
+select a, b from dn_t;
+→ [{"a":1,"b":1}]
+
+drop table dn_t;
+
+-- ===================================
+-- 6. Op-scoped constraints are filtered by the UPDATE mask, exactly as they are
+--    for a plain UPDATE: an `on insert`-only CHECK must NOT fire on this arm, an
+--    `on update`-only CHECK must.
+-- ===================================
+
+create table op_ins (a integer primary key, b integer, constraint only_ins check on insert (b < 10));
+insert into op_ins values (1, 1);
+
+-- the composed value 99 breaks the predicate, but the constraint is INSERT-scoped
+-- so the DO UPDATE arm does not enforce it.
+insert into op_ins values (1, 2) on conflict (a) do update set b = 99;
+select a, b from op_ins;
+→ [{"a":1,"b":99}]
+
+drop table op_ins;
+
+create table op_upd (a integer primary key, b integer, constraint only_upd check on update (b < 10));
+insert into op_upd values (1, 1);
+
+-- proposed row (b = 20) sails past the INSERT-shaped pass (the constraint is
+-- UPDATE-scoped); the composed row (b = 99) is caught by the arm.
+insert into op_upd values (1, 20) on conflict (a) do update set b = 99;
+-- error: CHECK constraint failed: only_upd (b < 10)
+
+select a, b from op_upd;
+→ [{"a":1,"b":1}]
+
+drop table op_upd;
+
+-- ===================================
+-- 7. A transition CHECK reading `old.<col>` sees the CONFLICTING STORED ROW as
+--    OLD — not the all-NULL OLD an INSERT would present.
+-- ===================================
+
+create table tr_t (a integer primary key, b integer, constraint monotonic check on update (b >= old.b));
+insert into tr_t values (1, 5);
+
+insert into tr_t values (1, 2) on conflict (a) do update set b = 1;
+-- error: CHECK constraint failed: monotonic (b >= old.b)
+
+select a, b from tr_t;
+→ [{"a":1,"b":5}]
+
+-- a non-decreasing composed value passes, which proves OLD really bound to the
+-- stored 5 rather than to NULL (a NULL OLD would make both directions pass).
+insert into tr_t values (1, 2) on conflict (a) do update set b = 9;
+select a, b from tr_t;
+→ [{"a":1,"b":9}]
+
+drop table tr_t;
+
+-- ===================================
+-- 8. Generated columns: the phase-2 recompute runs BEFORE validation, so a
+--    recomputed value is what the CHECK / NOT NULL sees.
+-- ===================================
+
+create table gen_ck (
+	a integer primary key,
+	x integer,
+	y integer generated always as (x * 10) stored,
+	check (y < 20)
+);
+insert into gen_ck (a, x) values (1, 1);
+
+insert into gen_ck (a, x) values (1, 5) on conflict (a) do update set x = 10;
+-- error: CHECK constraint failed: _check_0 (y < 20)
+
+select a, x, y from gen_ck;
+→ [{"a":1,"x":1,"y":10}]
+
+drop table gen_ck;
+
+create table gen_nn (
+	a integer primary key,
+	x integer,
+	y integer not null generated always as (case when x > 5 then null else x end) stored
+);
+insert into gen_nn (a, x) values (1, 1);
+
+insert into gen_nn (a, x) values (1, 2) on conflict (a) do update set x = 9;
+-- error: NOT NULL constraint failed: gen_nn.y
+
+select a, x, y from gen_nn;
+→ [{"a":1,"x":1,"y":1}]
+
+drop table gen_nn;
+
+-- ===================================
+-- 9. Per-constraint conflict defaults compose with the arm.
+--    `check (...) on conflict ignore` → the row is skipped silently: no error,
+--    nothing written.
+-- ===================================
+
+create table pc_ign (a integer primary key, b integer check (b < 10) on conflict ignore);
+insert into pc_ign values (1, 1);
+
+insert into pc_ign values (1, 2) on conflict (a) do update set b = 99;
+select a, b from pc_ign;
+→ [{"a":1,"b":1}]
+
+drop table pc_ign;
+
+-- `not null on conflict replace default <expr>` → the DEFAULT is substituted into
+-- the composed row, and that substituted row is what gets stored.
+create table pc_rep (a integer primary key, b integer not null on conflict replace default 7);
+insert into pc_rep values (1, 1);
+
+insert into pc_rep values (1, 2) on conflict (a) do update set b = null;
+select a, b from pc_rep;
+→ [{"a":1,"b":7}]
+
+drop table pc_rep;
+
+-- ===================================
+-- 10. Multi-row: row 1 updates cleanly, row 2 violates. Under the default ABORT
+--     the WHOLE statement rolls back — row 1's clean update is undone too.
+-- ===================================
+
+create table mr_t (id integer primary key, a integer, check (a < 10));
+insert into mr_t values (1, 1), (2, 2);
+
+insert into mr_t values (1, 0), (2, 0)
+	on conflict (id) do update set a = case when id = 1 then 3 else 99 end;
+-- error: CHECK constraint failed: _check_0 (a < 10)
+
+select id, a from mr_t order by id;
+→ [{"id":1,"a":1},{"id":2,"a":2}]
+
+drop table mr_t;
+
+-- ===================================
+-- 11. Multi-clause: both arms of one statement validate. The clause that matches
+--     is chosen by conflict target; whichever composes the row, the same
+--     UPDATE-shaped check set runs against it.
+-- ===================================
+
+create table mc_t (a integer primary key, e text unique, b integer, check (b < 10));
+insert into mc_t values (1, 'x', 1);
+
+-- conflicts on the PK → first clause composes b = 99.
+insert into mc_t values (1, 'y', 1)
+	on conflict (a) do update set b = 99
+	on conflict (e) do update set b = 5;
+-- error: CHECK constraint failed: _check_0 (b < 10)
+
+select a, e, b from mc_t;
+→ [{"a":1,"e":"x","b":1}]
+
+-- conflicts on the UNIQUE column → second clause composes b = 98.
+insert into mc_t values (2, 'x', 1)
+	on conflict (a) do update set b = 5
+	on conflict (e) do update set b = 98;
+-- error: CHECK constraint failed: _check_0 (b < 10)
+
+select a, e, b from mc_t;
+→ [{"a":1,"e":"x","b":1}]
+
+drop table mc_t;
+
+-- ===================================
+-- 12. Child-side foreign key: the composed row must still reference a live parent.
+-- ===================================
+
+pragma foreign_keys = true;
+
+create table fk_par (p integer primary key, n integer);
+create table fk_chi (c integer primary key, p integer references fk_par(p));
+insert into fk_par values (1, 0);
+insert into fk_chi values (1, 1);
+
+insert into fk_chi values (1, 1) on conflict (c) do update set p = 99;
+-- error: CHECK constraint failed: _fk_fk_chi_p
+
+select c, p from fk_chi;
+→ [{"c":1,"p":1}]
+
+update fk_chi set p = 99 where c = 1;
+-- error: CHECK constraint failed: _fk_fk_chi_p
+
+-- a composed value that DOES reference a live parent is accepted.
+insert into fk_par values (2, 0);
+insert into fk_chi values (1, 1) on conflict (c) do update set p = 2;
+select c, p from fk_chi;
+→ [{"c":1,"p":2}]
+
+drop table fk_chi;
+drop table fk_par;
+
+-- ===================================
+-- 13. Parent-side `on update restrict`: a DO UPDATE that changes a referenced
+--     column while a child still points at the old value is refused, with the SAME
+--     message the plain UPDATE of that parent row produces.
+--
+--     `rs_par` clears the batchability gate (one inbound FK, RESTRICT, not
+--     self-referencing), so a plain UPDATE skips the plan-time `not exists` probe and
+--     reports through the RESTRICT scan. The arm is gated the same way, and its own
+--     per-row `assertTransitiveRestrictsForParentMutation` pre-walk raises the same
+--     error. Section 13b covers the other side of that gate.
+-- ===================================
+
+create table rs_par (p integer primary key, n integer);
+create table rs_chi (c integer primary key, p integer references rs_par(p) on update restrict);
+insert into rs_par values (1, 0);
+insert into rs_chi values (1, 1);
+
+insert into rs_par values (1, 5) on conflict (p) do update set p = 2;
+-- error: FOREIGN KEY constraint failed: UPDATE on 'rs_par' violates RESTRICT from 'rs_chi'
+
+-- neither parent nor child moved: no dangling child was left behind.
+select p, n from rs_par;
+→ [{"p":1,"n":0}]
+select c, p from rs_chi;
+→ [{"c":1,"p":1}]
+
+-- the plain UPDATE spelling reports identically.
+update rs_par set p = 2 where p = 1;
+-- error: FOREIGN KEY constraint failed: UPDATE on 'rs_par' violates RESTRICT from 'rs_chi'
+
+-- changing a NON-referenced column through the same arm is fine.
+insert into rs_par values (1, 5) on conflict (p) do update set n = 5;
+select p, n from rs_par;
+→ [{"p":1,"n":5}]
+
+drop table rs_chi;
+drop table rs_par;
+
+-- ===================================
+-- 13b. The non-batchable side of the same gate: a parent with a mix of RESTRICT and
+--      CASCADE inbound FKs. A plain UPDATE keeps its plan-time `not exists` probe and
+--      reports through it; the DO UPDATE arm must do the same, so the two spellings
+--      stay in step on BOTH sides of the gate.
+-- ===================================
+
+create table mx_par (p integer primary key, n integer);
+create table mx_res (c integer primary key, p integer references mx_par(p) on update restrict);
+create table mx_cas (c integer primary key, p integer references mx_par(p) on update cascade);
+insert into mx_par values (1, 0);
+insert into mx_res values (1, 1);
+insert into mx_cas values (1, 1);
+
+insert into mx_par values (1, 5) on conflict (p) do update set p = 2;
+-- error: CHECK constraint failed: _fk_mx_res_p
+
+select p, n from mx_par;
+→ [{"p":1,"n":0}]
+select c, p from mx_res;
+→ [{"c":1,"p":1}]
+
+update mx_par set p = 2 where p = 1;
+-- error: CHECK constraint failed: _fk_mx_res_p
+
+drop table mx_cas;
+drop table mx_res;
+drop table mx_par;
+
+-- ===================================
+-- 14. Parent-side `on update cascade` still cascades through the DO UPDATE arm —
+--     regression guard; FK ACTIONS already fired before this fix, only the
+--     validation half was missing.
+-- ===================================
+
+create table cs_par (p integer primary key, n integer);
+create table cs_chi (c integer primary key, p integer references cs_par(p) on update cascade);
+insert into cs_par values (1, 0);
+insert into cs_chi values (1, 1);
+
+insert into cs_par values (1, 5) on conflict (p) do update set p = 2;
+select p, n from cs_par;
+→ [{"p":2,"n":0}]
+select c, p from cs_chi;
+→ [{"c":1,"p":2}]
+
+drop table cs_chi;
+drop table cs_par;
+
+pragma foreign_keys = false;
+
+-- ===================================
+-- 15. A CHECK carrying a subquery is auto-deferred, so the arm's check on the
+--     COMPOSED row is queued and evaluated at COMMIT — matching the plain UPDATE
+--     of the same row exactly. The proposed row here is legal (a = 5 < 10), so the
+--     failure can only come from the composed row (a = 99).
+-- ===================================
+
+create table df_t (id integer primary key, a integer, check (a < (select 10)));
+insert into df_t values (1, 1);
+
+begin;
+insert into df_t values (1, 5) on conflict (id) do update set a = 99;
+commit;
+-- error: CHECK constraint failed: _check_0 (a < (select 10))
+rollback;
+
+select id, a from df_t;
+→ [{"id":1,"a":1}]
+
+-- the plain UPDATE twin defers and fails at the same boundary with the same message.
+begin;
+update df_t set a = 99 where id = 1;
+commit;
+-- error: CHECK constraint failed: _check_0 (a < (select 10))
+rollback;
+
+select id, a from df_t;
+→ [{"id":1,"a":1}]
+
+drop table df_t;
+
+-- ===================================
+-- 16. Mutation-context variables resolve inside the arm's checks: an UPDATE-scoped
+--     CHECK referencing a context variable binds the value the executor evaluated
+--     for this statement.
+-- ===================================
+
+create table cx_t (a integer primary key, b integer, constraint under_who check on update (b < who))
+	with context (who integer);
+insert into cx_t values (1, 1) with context who = 100;
+
+insert into cx_t values (1, 2) on conflict (a) do update set b = 99 with context who = 10;
+-- error: CHECK constraint failed: under_who (b < who)
+
+select a, b from cx_t;
+→ [{"a":1,"b":1}]
+
+-- same statement, a context value the composed row satisfies.
+insert into cx_t values (1, 2) on conflict (a) do update set b = 99 with context who = 1000;
+select a, b from cx_t;
+→ [{"a":1,"b":99}]
+
+drop table cx_t;

package/test/logic/47.6-upsert-do-update-decomposed.sqllogic

@@ -0,0 +1,100 @@
+-- The `on conflict ... do update` arm is also reached by writes nobody spelled as an
+-- UPSERT. An UPDATE through a logical (lens) table whose columns are split across
+-- decomposition members lowers an optional member's anchor-resolvable assignment to a
+-- synthesized `insert into <member> (...) select ... on conflict (<key>) do update set
+-- <col> = excluded.<col>` (planner/mutation/decomposition.ts,
+-- buildOptionalMemberInsertSelect with action 'update'). Rows whose member tuple already
+-- exists take the DO UPDATE arm, so the arm's validation has to hold there too.
+--
+-- Companion to 47.5, which pins the user-spelled arm. Ticket
+-- bug-upsert-do-update-skips-constraint-checks.
+--
+-- The member CHECK is UPDATE-scoped on purpose: an unscoped one would already be caught
+-- by the INSERT-shaped pass over the proposed row, so only an `on update` CHECK proves
+-- the ARM is what refused the write.
+
+-- ===================================
+-- Basis: anchor Car_core + optional Car_perf, sharing logical key `id`, advertised
+-- through quereus.lens.decomp.* tags (same construction as 51-lens-foundation § 4).
+-- ===================================
+
+create table Car_core (id integer primary key, make text) with tags (
+	"quereus.lens.decomp.logical.d1" = 'Car',
+	"quereus.lens.decomp.role.d1" = 'primary-storage',
+	"quereus.lens.decomp.anchor.d1" = 'Car_core',
+	"quereus.lens.decomp.presence.d1" = 'mandatory',
+	"quereus.lens.decomp.keykind.d1" = 'logical-tuple',
+	"quereus.lens.decomp.key.d1" = 'id',
+	"quereus.lens.decomp.col.d1.id" = 'id',
+	"quereus.lens.decomp.col.d1.make" = 'make'
+);
+
+create table Car_perf (
+	id integer primary key,
+	speed integer null,
+	constraint slow_only check on update (speed < 100)
+) with tags (
+	"quereus.lens.decomp.logical.d1" = 'Car',
+	"quereus.lens.decomp.role.d1" = 'primary-storage',
+	"quereus.lens.decomp.anchor.d1" = 'Car_core',
+	"quereus.lens.decomp.presence.d1" = 'optional',
+	"quereus.lens.decomp.keykind.d1" = 'logical-tuple',
+	"quereus.lens.decomp.key.d1" = 'id',
+	"quereus.lens.decomp.col.d1.maxSpeed" = 'speed'
+);
+
+-- run
+
+insert into Car_core values (1, 'Honda'), (2, 'Mazda');
+insert into Car_perf values (1, 10);
+
+-- run
+
+declare logical schema appcar {
+	table Car {
+		id integer primary key,
+		make text,
+		maxSpeed integer null
+	}
+}
+
+-- run
+
+declare lens for appcar over main { }
+
+-- run
+
+apply schema appcar;
+
+-- run
+
+select * from appcar.Car order by id;
+→ [{"id": 1, "make": "Honda", "maxSpeed": 10}, {"id": 2, "make": "Mazda", "maxSpeed": null}]
+
+-- ===================================
+-- An anchor-resolvable assignment (`id * 1000`, computable over the anchor scan) takes
+-- the single-statement flavour: absent member rows insert, present ones take DO UPDATE.
+-- Car 1's member row exists, so its composed row is the arm's, and the UPDATE-scoped
+-- CHECK refuses it.
+-- ===================================
+
+update appcar.Car set maxSpeed = id * 1000 where id = 1;
+-- error: CHECK constraint failed: slow_only (speed < 100)
+
+-- nothing moved on either member.
+select id, speed from Car_perf order by id;
+→ [{"id": 1, "speed": 10}]
+select * from appcar.Car order by id;
+→ [{"id": 1, "make": "Honda", "maxSpeed": 10}, {"id": 2, "make": "Mazda", "maxSpeed": null}]
+
+-- ===================================
+-- The same statement shape with a value the CHECK admits writes through: car 1 takes the
+-- DO UPDATE arm, car 2 (no member row) materializes through the INSERT branch — where
+-- the UPDATE-scoped CHECK correctly does NOT apply.
+-- ===================================
+
+update appcar.Car set maxSpeed = id * 10;
+select id, speed from Car_perf order by id;
+→ [{"id": 1, "speed": 10}, {"id": 2, "speed": 20}]
+select * from appcar.Car order by id;
+→ [{"id": 1, "make": "Honda", "maxSpeed": 10}, {"id": 2, "make": "Mazda", "maxSpeed": 20}]

package/test/logic/49-reference-graph.sqllogic

@@ -0,0 +1,84 @@
+-- Test Reference Graph and Materialization Advisory
+
+-- Basic setup
+CREATE TABLE t1 (id INTEGER PRIMARY KEY, value INTEGER);
+CREATE TABLE t2 (id INTEGER PRIMARY KEY, t1_id INTEGER);
+INSERT INTO t1 VALUES (1, 10), (2, 20), (3, 30);
+INSERT INTO t2 VALUES (1, 1), (2, 1), (3, 2), (4, 2), (5, 3);
+
+-- Test 1: Multiple references to same subquery should trigger caching
+-- The subquery (SELECT * FROM t1 WHERE value > 15) is referenced twice
+SELECT
+    (SELECT COUNT(*) FROM (SELECT * FROM t1 WHERE value > 15) AS sub1) AS count1,
+    (SELECT SUM(value) FROM (SELECT * FROM t1 WHERE value > 15) AS sub2) AS sum1
+→ [{"count1": 2, "sum1": 50}]
+
+-- Test 2: Nested loop join - right side should be cached
+-- This tests loop context detection
+SELECT t1.id, COUNT(t2.id) AS cnt
+FROM t1
+JOIN t2 ON t1.id = t2.t1_id
+GROUP BY t1.id
+ORDER BY t1.id
+→ [{"id": 1, "cnt": 2}, {"id": 2, "cnt": 2}, {"id": 3, "cnt": 1}]
+
+-- Test 3: Correlated subquery pattern
+-- The subquery executes once per outer row
+SELECT
+    t1.id,
+    (SELECT COUNT(*) FROM t2 WHERE t2.t1_id = t1.id) AS count
+FROM t1
+ORDER BY t1.id
+→ [{"id": 1, "count": 2}, {"id": 2, "count": 2}, {"id": 3, "count": 1}]
+
+-- Test 4: EXISTS subquery pattern
+SELECT COUNT(*) AS cnt
+FROM t1
+WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.t1_id = t1.id)
+→ [{"cnt": 3}]
+
+-- Test 5: IN subquery pattern
+SELECT COUNT(*) AS cnt
+FROM t1
+WHERE id IN (SELECT DISTINCT t1_id FROM t2)
+→ [{"cnt": 3}]
+
+-- Test 6: CTE with multiple references
+-- The CTE is referenced twice and should be cached
+WITH high_values AS (
+    SELECT * FROM t1 WHERE value >= 20
+)
+SELECT
+    (SELECT COUNT(*) FROM high_values) AS count,
+    (SELECT SUM(value) FROM high_values) AS sum
+→ [{"count": 2, "sum": 50}]
+
+-- Test 7: Complex query with multiple caching opportunities
+WITH base AS (
+    SELECT t1.*, COUNT(t2.id) AS ref_count
+    FROM t1
+    LEFT JOIN t2 ON t1.id = t2.t1_id
+    GROUP BY t1.id, t1.value
+)
+SELECT
+    b1.id,
+    b1.ref_count,
+    (SELECT COUNT(*) FROM base b2 WHERE b2.ref_count > b1.ref_count) AS higher_count
+FROM base b1
+ORDER BY b1.id
+→ [{"id": 1, "ref_count": 2, "higher_count": 0}, {"id": 2, "ref_count": 2, "higher_count": 0}, {"id": 3, "ref_count": 1, "higher_count": 2}]
+
+-- Test 8: Non-deterministic functions should not be cached
+-- Verify that query plans with random() do not contain cache nodes
+CREATE TABLE t3 (id INTEGER PRIMARY KEY);
+INSERT INTO t3 VALUES (1), (2), (3);
+
+-- Check that no Cache nodes are present in the plan for non-deterministic subquery
+SELECT COUNT(*) AS cache_count FROM query_plan('SELECT (SELECT id FROM t3 ORDER BY random() LIMIT 1) AS x FROM t3') WHERE op = 'CACHE'
+→ [{"cache_count": 0}]
+
+-- Test 9: CTE with MATERIALIZED hint buffers via the `materialize` mark, not a CACHE node
+-- This CTE has an explicit materialization hint; emitCTE buffers it once per execution
+-- (CTENode.materialize), so no separate CacheNode wrap is injected.
+SELECT COUNT(*) AS cache_count FROM query_plan('WITH high_values AS MATERIALIZED (SELECT * FROM t1 WHERE value >= 20) SELECT COUNT(*) FROM high_values') WHERE op = 'CACHE'
+→ [{"cache_count": 0}]