@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/13.11-unreferenced-dml-cte.sqllogic

@@ -0,0 +1,414 @@
+-- 13.11-unreferenced-dml-cte.sqllogic - an UNREFERENCED data-modifying CTE still runs
+--
+-- A top-level statement's `with` clause naming an `insert`/`update`/`delete` member
+-- performs that member's write exactly once per statement execution, whether or not the
+-- rest of the statement names it — matching SQLite and PostgreSQL, for which the write
+-- is a stated effect of the statement, not an optimization the engine may skip.
+--
+-- Mechanics: `buildBlock` detects a member whose runtime identity (the CTE's
+-- tableDescriptor, memoized per source member in PlanningContext.cteDescriptors) is
+-- absent from the built plan, rebuilds the clause, and sequences a Sink over each such
+-- member AHEAD of the statement (SequenceNode). Effects-first is deliberate: a main
+-- statement abandoned early (limit 0) must not skip the write.
+--
+-- Known divergence from PostgreSQL, accepted and documented in
+-- docs/runtime-caching.md § Shared CTE materialization: because the write runs before
+-- the main statement, the outer query CAN observe it (PostgreSQL's sub-statements never
+-- see one another's effects). Consistent with Quereus's existing behaviour for
+-- referenced members, whose writes the outer query can also observe.
+
+-- ===== INSERT body, never referenced =====
+
+create table t1 (k integer primary key);
+-- run
+
+-- Result shape must survive the sequencing wrapper: `x`, not a synthesized name.
+with c as (insert into t1 (k) values (1) returning k) select 42 as x;
+→ [{"x":42}]
+
+select k from t1 order by k;
+→ [{"k":1}]
+
+-- ===== UPDATE body, never referenced =====
+
+create table t2 (k integer primary key, v integer);
+insert into t2 values (1, 0), (2, 0);
+-- run
+
+with c as (update t2 set v = v + 1 returning k) select 42 as x;
+→ [{"x":42}]
+
+select k, v from t2 order by k;
+→ [{"k":1,"v":1},{"k":2,"v":1}]
+
+-- ===== DELETE body, never referenced =====
+
+create table t3 (k integer primary key);
+insert into t3 values (1), (2), (3);
+-- run
+
+with c as (delete from t3 where k < 3 returning k) select 42 as x;
+→ [{"x":42}]
+
+select k from t3 order by k;
+→ [{"k":3}]
+
+-- ===== Unreferenced member under an outer INSERT =====
+-- The write and the outer statement's own write must run sequentially — interleaving
+-- them broke statement-savepoint pairing on a prototype that nested a BlockNode.
+
+create table t4a (k integer primary key);
+create table t4b (k integer primary key);
+-- run
+
+with c as (insert into t4a (k) values (1) returning k) insert into t4b (k) values (2);
+-- run
+
+select k from t4a order by k;
+→ [{"k":1}]
+
+select k from t4b order by k;
+→ [{"k":2}]
+
+-- ===== Unreferenced member under an outer UPDATE =====
+
+create table t5a (k integer primary key);
+create table t5b (k integer primary key, v integer);
+insert into t5b values (1, 0);
+-- run
+
+with c as (insert into t5a (k) values (7) returning k) update t5b set v = v + 1;
+-- run
+
+select k from t5a order by k;
+→ [{"k":7}]
+
+select k, v from t5b order by k;
+→ [{"k":1,"v":1}]
+
+-- ===== Unreferenced member under an outer DELETE =====
+
+create table t6a (k integer primary key);
+create table t6b (k integer primary key);
+insert into t6b values (1), (2);
+-- run
+
+with c as (insert into t6a (k) values (7) returning k) delete from t6b where k = 1;
+-- run
+
+select k from t6a order by k;
+→ [{"k":7}]
+
+select k from t6b order by k;
+→ [{"k":2}]
+
+-- ===== Two unreferenced members in one clause =====
+-- Both write, in clause order, exactly once each.
+
+create table t7a (k integer primary key);
+create table t7b (k integer primary key);
+-- run
+
+with a as (insert into t7a (k) values (1) returning k),
+     b as (insert into t7b (k) values (2) returning k)
+select 42 as x;
+→ [{"x":42}]
+
+select k from t7a order by k;
+→ [{"k":1}]
+
+select k from t7b order by k;
+→ [{"k":2}]
+
+-- ===== One referenced + one unreferenced member =====
+-- Exactly one write each: the sink rebuild shares the referenced member's runtime
+-- identity, so it cannot double the referenced write.
+
+create table t8a (k integer primary key);
+create table t8b (k integer primary key);
+-- run
+
+with a as (insert into t8a (k) values (1) returning k),
+     b as (insert into t8b (k) values (2) returning k)
+select k from a;
+→ [{"k":1}]
+
+select k from t8a order by k;
+→ [{"k":1}]
+
+select k from t8b order by k;
+→ [{"k":2}]
+
+-- ===== An unreferenced writing member reading a referenced sibling =====
+-- The rebuild replays the referenced member's one buffer instead of re-driving its
+-- write: `a` writes once even though the sunk `b` reads it.
+
+create table t9a (k integer primary key);
+create table t9b (k integer primary key);
+-- run
+
+with a as (insert into t9a (k) values (1) returning k),
+     b as (insert into t9b (k) select k + 10 from a returning k)
+select k from a;
+→ [{"k":1}]
+
+select k from t9a order by k;
+→ [{"k":1}]
+
+select k from t9b order by k;
+→ [{"k":11}]
+
+-- ===== Transitively unreferenced: reachable only from another unreferenced member =====
+-- `d` reads `c` but nothing reads `d`; `c`'s write still runs exactly once (the select
+-- member `d` is NOT sunk — only data-modifying members are).
+
+create table t10 (k integer primary key);
+-- run
+
+with c as (insert into t10 (k) values (1) returning k),
+     d as (select k from c)
+select 42 as x;
+→ [{"x":42}]
+
+select k from t10 order by k;
+→ [{"k":1}]
+
+-- ===== Two unreferenced writing members, second reading the first =====
+-- Sunk in clause order: `c` writes and buffers, `d`'s drive replays that buffer.
+-- One write each.
+
+create table t11a (k integer primary key);
+create table t11b (k integer primary key);
+-- run
+
+with c as (insert into t11a (k) values (1) returning k),
+     d as (insert into t11b (k) select k + 10 from c returning k)
+select 42 as x;
+→ [{"x":42}]
+
+select k from t11a order by k;
+→ [{"k":1}]
+
+select k from t11b order by k;
+→ [{"k":11}]
+
+-- ===== LIMIT 0 on the main statement does NOT skip the write =====
+-- The prelude runs before the main statement, so early abandonment cannot starve it.
+
+create table t12 (k integer primary key);
+-- run
+
+with c as (insert into t12 (k) values (1) returning k) select 42 as x limit 0;
+→ []
+
+select k from t12 order by k;
+→ [{"k":1}]
+
+-- ===== The outer statement CAN observe the write (documented divergence) =====
+-- PostgreSQL would answer 1 here (sub-statements never see one another's effects);
+-- Quereus sequences the write first, consistent with its existing visibility for
+-- referenced members. See docs/runtime-caching.md § Shared CTE materialization.
+
+create table t13 (k integer primary key);
+insert into t13 values (1);
+-- run
+
+with c as (insert into t13 (k) values (2) returning k) select count(*) as n from t13;
+→ [{"n":2}]
+
+-- ===== Unreferenced member alongside a VIEW-targeted outer write =====
+-- The view write-through path re-plans the statement (building the clause 2+ times);
+-- the shared runtime identity keeps it to ONE write, and the unreferenced-member scan
+-- keys off that same identity so the member is not double-sunk either.
+
+create table t14log (id integer primary key, v text);
+create table t14 (id integer primary key, w text);
+create view vt14 as select id, w from t14;
+-- run
+
+with d as (insert into t14log values (1, 'x') returning id)
+insert into vt14 values (5, 'z');
+-- run
+
+select id, v from t14log order by id;
+→ [{"id":1,"v":"x"}]
+
+select id, w from t14 order by id;
+→ [{"id":5,"w":"z"}]
+
+-- Multi-source view target: a join-bodied view decomposes into one base insert per
+-- member, each re-entering the INSERT builder — none of those extra plannings may run
+-- (or sink) the unreferenced member's write again.
+
+create table t15log (id integer primary key, v text);
+create table t15a (id integer primary key, a text);
+create table t15b (id integer primary key, b text);
+create view vt15 as select t15a.id as id, t15a.a as a, t15b.b as b
+  from t15a join t15b on t15a.id = t15b.id;
+-- run
+
+with d as (insert into t15log values (1, 'x') returning id)
+insert into vt15 values (5, 'aa', 'bb');
+-- run
+
+select id, v from t15log order by id;
+→ [{"id":1,"v":"x"}]
+
+select id, a from t15a order by id;
+→ [{"id":5,"a":"aa"}]
+
+select id, b from t15b order by id;
+→ [{"id":5,"b":"bb"}]
+
+-- ===== ROLLBACK undoes a sunk write =====
+-- The prelude write goes through the ordinary DML path; nothing about the sink
+-- shields it from transaction rollback.
+
+create table t16 (k integer primary key);
+-- run
+
+begin;
+-- run
+
+with c as (insert into t16 (k) values (1) returning k) select 42 as x;
+→ [{"x":42}]
+
+rollback;
+-- run
+
+select count(*) as cnt from t16;
+→ [{"cnt":0}]
+
+-- ===== Control: an unreferenced SELECT-bodied member is still dropped =====
+-- Only data-modifying members carry an obligation to run; a read-only member nobody
+-- names has no observable effect and stays unplanned.
+
+create table t17 (k integer primary key);
+insert into t17 values (1);
+-- run
+
+with c as (select k from t17) select 42 as x;
+→ [{"x":42}]
+
+-- ===== A compound (UNION ALL) main statement still carries the clause =====
+-- The attach site reads the clause off the TOP statement node; a compound main must not
+-- hide it on an arm.
+
+create table t22 (k integer primary key);
+-- run
+
+with c as (insert into t22 (k) values (1) returning k)
+select 42 as x union all select 43 as x;
+→ [{"x":42},{"x":43}]
+
+select k from t22 order by k;
+→ [{"k":1}]
+
+-- ===== A bind parameter inside the unreferenced member's body still binds =====
+-- The member is rebuilt for the sink AFTER the statement is planned; the rebuild must
+-- reach the same parameter, not a second unbound one.
+
+create table t18 (k integer primary key);
+-- run
+
+-- params: [7]
+with c as (insert into t18 (k) values (?) returning k) select 42 as x;
+→ [{"x":42}]
+
+select k from t18 order by k;
+→ [{"k":7}]
+
+-- ===== A failing sunk write surfaces its error, it is not swallowed =====
+
+create table t19 (k integer primary key);
+insert into t19 values (1);
+-- run
+
+with c as (insert into t19 (k) values (1) returning k) select 42 as x;
+-- error: UNIQUE constraint failed
+
+select count(*) as cnt from t19;
+→ [{"cnt":1}]
+
+-- ===== A failing MAIN statement rolls the prelude write back with it =====
+-- The prelude is part of the statement, not a statement of its own: one statement
+-- savepoint covers both, so a main-statement failure undoes the sunk write.
+
+create table t20 (k integer primary key);
+create table t20u (k integer primary key);
+insert into t20u values (1);
+-- run
+
+with c as (insert into t20 (k) values (1) returning k) insert into t20u (k) values (1);
+-- error: UNIQUE constraint failed
+
+select count(*) as cnt from t20;
+→ [{"cnt":0}]
+
+-- ===== The statement's WITH SCHEMA steers the sunk member's write =====
+-- The sink rebuild runs on its own context, which must mirror the statement's schema
+-- path — else the write resolves the bare name against the SESSION path instead.
+
+create table main.t21 (k integer primary key);
+create table temp.t21 (k integer primary key);
+pragma schema_path = 'temp';
+-- run
+
+with c as (insert into t21 (k) values (1) returning k) select 42 as x with schema main;
+→ [{"x":42}]
+
+select count(*) as cnt from main.t21;
+→ [{"cnt":1}]
+
+select count(*) as cnt from temp.t21;
+→ [{"cnt":0}]
+
+-- Control: with no statement schema path, the SESSION path (temp) takes the write.
+
+with c as (insert into t21 (k) values (2) returning k) select 42 as x;
+→ [{"x":42}]
+
+select count(*) as cnt from temp.t21;
+→ [{"cnt":1}]
+
+pragma schema_path = 'main';
+-- run
+
+-- Cleanup
+drop table t1;
+drop table t2;
+drop table t3;
+drop table t4a;
+drop table t4b;
+drop table t5a;
+drop table t5b;
+drop table t6a;
+drop table t6b;
+drop table t7a;
+drop table t7b;
+drop table t8a;
+drop table t8b;
+drop table t9a;
+drop table t9b;
+drop table t10;
+drop table t11a;
+drop table t11b;
+drop table t12;
+drop table t13;
+drop view vt14;
+drop table t14;
+drop table t14log;
+drop view vt15;
+drop table t15a;
+drop table t15b;
+drop table t15log;
+drop table t16;
+drop table t17;
+drop table t18;
+drop table t19;
+drop table t20;
+drop table t20u;
+drop table main.t21;
+drop table temp.t21;
+drop table t22;
+-- run

package/test/logic/13.12-nested-dml-cte-rejected.sqllogic

@@ -0,0 +1,280 @@
+-- 13.12-nested-dml-cte-rejected.sqllogic - a data-modifying `with` member is legal
+-- ONLY in a statement's own leading WITH clause
+--
+-- A member whose body is an `insert` / `update` / `delete` carries a write that must
+-- happen exactly once per statement execution. Only a statement's OWN leading clause has
+-- an owner for that guarantee: `attachUnreferencedDmlCtes` (planner/building/block.ts),
+-- which only ever sees top-level statements. In every other position the write is driven
+-- by whoever happens to reference the member — silently dropped when nothing does,
+-- re-driven on every read when the position is a stored view body, and once for the whole
+-- statement rather than once per outer row when the position is a correlated subquery.
+--
+-- `buildWithClause` (planner/building/with.ts) therefore rejects such a member in any
+-- clause `buildBlock` did not mark as a top-level statement's own. Same rationale (and
+-- same permanent-rejection status) as `planViewBody`'s refusal of a DML view *body*.
+-- PostgreSQL rejects every shape below too.
+--
+-- Coverage below: one case per nesting position, REFERENCED and UNREFERENCED (both must
+-- reject — the unreferenced ones are the reported bug, the referenced ones are a
+-- deliberate narrowing of shapes that used to write). Positive controls at the end pin
+-- that the top-level clause still writes and that read-only nested clauses are untouched.
+
+create table t (k integer primary key);
+create table src (k integer primary key);
+create table dst (id integer primary key, v integer);
+insert into dst values (1, 10), (2, 20);
+-- run
+
+-- ===== FROM sub-query =====
+-- Unreferenced: the reported bug. This used to return the row and write nothing.
+
+select * from (with c as (insert into t (k) values (1) returning k) select 42 as x) z;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- Referenced: used to write once per statement execution. Narrowed to a rejection so
+-- position, not reachability, decides.
+
+select * from (with c as (insert into t (k) values (1) returning k) select k as x from c) z;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- Nothing was written by either.
+
+select count(*) as n from t;
+→ [{"n":0}]
+
+-- ===== Scalar sub-query =====
+
+select (with c as (insert into t (k) values (1) returning k) select k from c) as x;
+-- error: only allowed in a statement's own leading WITH clause
+
+select (with c as (insert into t (k) values (1) returning k) select 42) as x;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== EXISTS sub-query =====
+
+select 1 as x where exists (with c as (insert into t (k) values (1) returning k) select k from c);
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== IN sub-query =====
+
+select id from dst where id in (with c as (insert into t (k) values (1) returning k) select k from c);
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== A clause nested inside a top-level CTE's body =====
+-- The OUTER clause is the statement's own and would be fine; the inner one is not.
+
+with o as (with c as (insert into t (k) values (1) returning k) select k from c)
+select k from o;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== A compound arm's own clause =====
+-- The attach site reads the clause off the TOP statement node, so an arm's own clause has
+-- no owner even though the compound as a whole is top-level.
+
+select 1 as x
+union all
+select x from (with c as (insert into t (k) values (1) returning k) select k as x from c) z;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== A nested clause feeding an outer INSERT =====
+
+insert into t (k) select x from (with c as (insert into src (k) values (1) returning k) select k as x from c) z;
+-- error: only allowed in a statement's own leading WITH clause
+
+select count(*) as n from src;
+→ [{"n":0}]
+
+-- ===== A nested clause in an UPDATE ... WHERE =====
+
+update dst set v = 99 where id in (select x from (with c as (insert into src (k) values (1) returning k) select k as x from c) z);
+-- error: only allowed in a statement's own leading WITH clause
+
+select id, v from dst order by id;
+→ [{"id":1,"v":10},{"id":2,"v":20}]
+
+-- ===== A nested clause in a DELETE ... WHERE =====
+
+delete from dst where id in (select x from (with c as (insert into src (k) values (1) returning k) select k as x from c) z);
+-- error: only allowed in a statement's own leading WITH clause
+
+select count(*) as n from dst;
+→ [{"n":2}]
+
+-- ===== Stored view body =====
+-- Referenced: this used to CREATE, and then re-drive the write on every read of the view.
+
+create view v_dml as with c as (insert into t (k) values (1) returning k) select k as x from c;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- Unreferenced: this used to create a view that silently wrote nothing.
+
+create view v_dml_unref as with c as (insert into t (k) values (1) returning k) select 42 as x;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== Materialized-view body =====
+-- Replaces a late, confusing "body is non-deterministic (SINK (unreferenced-cte c))".
+
+create materialized view mv_dml as with c as (insert into t (k) values (1) returning k) select k as x from c;
+-- error: only allowed in a statement's own leading WITH clause
+
+create materialized view mv_dml_unref as with c as (insert into t (k) values (1) returning k) select 42 as x;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- Nothing above wrote anything, and no object was defined.
+
+select count(*) as n from t;
+→ [{"n":0}]
+
+select count(*) as n from src;
+→ [{"n":0}]
+
+-- ===== Maintained-table body =====
+
+create table mt_dml (k integer primary key) maintained as with c as (insert into t (k) values (1) returning k) select k from c;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== Assertion body =====
+-- Wrapped in the create-assertion diagnostic, so match on the inner text.
+
+create assertion a_dml check (not exists (with c as (insert into t (k) values (1) returning k) select k from c));
+-- error: only allowed in a statement's own leading WITH clause
+
+-- No object survived any of the four rejected definitions — the reject fires while the
+-- body is planned, which is before the definition is registered.
+
+select count(*) as n from view_info() where name in ('v_dml', 'v_dml_unref', 'mv_dml', 'mv_dml_unref');
+→ [{"n":0}]
+
+select count(*) as n from assertion_info() where name = 'a_dml';
+→ [{"n":0}]
+
+select k from mt_dml;
+-- error: not found
+
+-- ===== `with recursive` in a nested position =====
+-- The `recursive` keyword does not buy a data-modifying member a nested position: a
+-- non-compound DML member is not itself recursive, so it reaches the same gate.
+
+select * from (with recursive c as (insert into t (k) values (1) returning k) select k as x from c) z;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== Two nesting levels =====
+-- The gate is on the clause, not on the position, so depth does not matter: a clause
+-- reached through a read-only nested clause rejects exactly the same.
+
+select n from (with z as (select x as k from (with c as (insert into t (k) values (1) returning k) select k as x from c) w) select k as n from z) q;
+-- error: only allowed in a statement's own leading WITH clause
+
+-- ===== Correlated scalar sub-query =====
+-- The shape `docs/runtime-caching.md` used to list as an open gap: it wrote once for the
+-- whole statement rather than once per outer row, and every outer row saw the first row's
+-- RETURNING set. Now unreachable.
+
+insert into src values (7), (8);
+-- run
+
+select (select x from (with c as (insert into t (k) values (src.k) returning k) select k as x from c) z) as n from src;
+-- error: only allowed in a statement's own leading WITH clause
+
+select count(*) as n from t;
+→ [{"n":0}]
+
+delete from src;
+-- run
+
+-- ===== UPDATE and DELETE bodies reject in a nested position too =====
+
+create table upd (k integer primary key, v integer);
+insert into upd values (1, 0);
+-- run
+
+select * from (with c as (update upd set v = v + 1 returning k) select 42 as x) z;
+-- error: only allowed in a statement's own leading WITH clause
+
+select * from (with c as (delete from upd where k = 1 returning k) select 42 as x) z;
+-- error: only allowed in a statement's own leading WITH clause
+
+select k, v from upd order by k;
+→ [{"k":1,"v":0}]
+
+-- ===== Positive control: the statement's own leading clause still writes =====
+-- Referenced and unreferenced, for INSERT / UPDATE / DELETE — the guarantee 13.11 pins,
+-- re-checked here so the rejection cannot swallow it.
+
+with c as (insert into t (k) values (1) returning k) select k as x from c;
+→ [{"x":1}]
+
+with c as (insert into t (k) values (2) returning k) select 42 as x;
+→ [{"x":42}]
+
+select k from t order by k;
+→ [{"k":1},{"k":2}]
+
+with c as (update upd set v = v + 1 returning k) select 42 as x;
+→ [{"x":42}]
+
+with c as (delete from upd where k = 1 returning k) select 42 as x;
+→ [{"x":42}]
+
+select count(*) as n from upd;
+→ [{"n":0}]
+
+-- A leading clause on an outer INSERT / UPDATE / DELETE is equally its own.
+
+with c as (insert into src (k) values (5) returning k) insert into t (k) select k + 100 from c;
+-- run
+
+select k from src order by k;
+→ [{"k":5}]
+
+select k from t order by k;
+→ [{"k":1},{"k":2},{"k":105}]
+
+-- ===== Positive control: a READ-ONLY nested clause is untouched =====
+-- Only `isDataModifyingCte` members are rejected; 13.7-cte-sibling-visibility covers this
+-- ground in depth, these pin the exact positions the rejection walks past.
+
+select n from (with z as (select 1 as k) select k as n from z) q;
+→ [{"n":1}]
+
+select (with z as (select 7 as k) select k from z) as x;
+→ [{"x":7}]
+
+select id from dst where id in (with z as (select 1 as k) select k from z);
+→ [{"id":1}]
+
+create view v_ro as with z as (select 3 as k) select k as x from z;
+-- run
+
+select x from v_ro;
+→ [{"x":3}]
+
+-- (a materialized view's body must read a source table, hence `mvsrc` rather than a
+-- literal block — orthogonal to what this file pins.)
+create table mvsrc (k integer primary key);
+insert into mvsrc values (4);
+create materialized view mv_ro as with z as (select k from mvsrc) select k as x from z;
+-- run
+
+select x from mv_ro;
+→ [{"x":4}]
+
+-- A read-only clause nested inside a DML CTE body in a TOP-LEVEL clause still works:
+-- the outer clause is the statement's own, and the inner one is not data-modifying.
+
+with c as (with z as (select 300 as k) insert into src (k) select k from z returning k)
+select k as x from c;
+→ [{"x":300}]
+
+select k from src order by k;
+→ [{"k":5},{"k":300}]
+
+-- Cleanup
+drop materialized view mv_ro;
+drop view v_ro;
+drop table t;
+drop table src;
+drop table dst;
+drop table upd;
+drop table mvsrc;
+-- run