@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/13.8-insert-with-clause-visibility.sqllogic

@@ -0,0 +1,254 @@
+-- 13.8-insert-with-clause-visibility.sqllogic - a leading WITH on INSERT reaches every clause
+--
+-- `buildInsertStmt` used to build its leading `with` clause into a local map handed to
+-- exactly ONE consumer — the `select` source branch — instead of deriving one
+-- statement-level planning context the way `buildUpdateStmt` / `buildDeleteStmt` do. Every
+-- other clause of the same statement therefore lost the statement's CTEs and failed with
+-- `Table 'c' not found in schema path: main`: RETURNING, a scalar subquery inside a VALUES
+-- row, ON CONFLICT, WITH CONTEXT, and the view / materialized-view target dispatch.
+--
+-- The same local map also started EMPTY and was filled from the INSERT's own `with` clause
+-- alone, while `buildWithContext` prefers a non-empty explicit argument over the context's
+-- inherited definitions — so an INSERT that carried its own `with` clause dropped every
+-- definition it had inherited from an enclosing statement. That arm is covered at the end.
+
+create table p (id integer primary key, v text);
+insert into p values (1, 'a'), (2, 'b');
+-- run
+
+-- ===== RETURNING sees the statement's CTEs =====
+
+create table q1 (id integer primary key, w text);
+-- run
+
+with c as (select id, v from p) insert into q1 values (5, 'e')
+  returning id, (select count(*) from c) as n;
+→ [{"id":5,"n":2}]
+
+select id, w from q1 order by id;
+→ [{"id":5,"w":"e"}]
+
+-- ===== A scalar subquery inside a VALUES row sees them =====
+
+create table q2 (id integer primary key, w integer);
+-- run
+
+with c as (select id from p) insert into q2 values (6, (select count(*) from c));
+
+select id, w from q2 order by id;
+→ [{"id":6,"w":2}]
+
+-- ===== A view target sees them (source AND returning) =====
+
+create table q3 (id integer primary key, w text);
+create view vq3 as select id, w from q3;
+-- run
+
+with c as (select id, v from p) insert into vq3 select id, v from c;
+
+select id, w from q3 order by id;
+→ [{"id":1,"w":"a"},{"id":2,"w":"b"}]
+
+with c as (select id from p) insert into vq3 values (7, 'g')
+  returning id, (select count(*) from c) as n;
+→ [{"id":7,"n":2}]
+
+-- ===== A materialized-view target sees them =====
+
+create table q4 (id integer primary key, w text);
+create materialized view mvq4 as select id, w from q4;
+-- run
+
+with c as (select id, v from p) insert into mvq4 select id, v from c;
+
+select id, w from q4 order by id;
+→ [{"id":1,"w":"a"},{"id":2,"w":"b"}]
+
+select id, w from mvq4 order by id;
+→ [{"id":1,"w":"a"},{"id":2,"w":"b"}]
+
+-- ===== Nested DML source sees them =====
+-- `insert into … insert into … returning` — the inner DML builds on the same context.
+
+create table q5 (id integer primary key, w text);
+create table q5src (id integer primary key, w text);
+-- run
+
+with c as (select id from p)
+insert into q5 insert into q5src values (8, 'h') returning id + (select count(*) from c), w;
+
+select id, w from q5 order by id;
+→ [{"id":10,"w":"h"}]
+
+-- The UPDATE- and DELETE-bodied source branches take the same context.
+
+create table q5b (id integer primary key, w integer);
+create table q5c (id integer primary key, w integer);
+create table q5upd (id integer primary key, w text);
+insert into q5upd values (1, 'x'), (2, 'y');
+-- run
+
+with c as (select id from p)
+insert into q5b update q5upd set w = 'z' where id = 1 returning id, (select count(*) from c);
+
+select id, w from q5b order by id;
+→ [{"id":1,"w":2}]
+
+with c as (select id from p)
+insert into q5c delete from q5upd where id = 2 returning id, (select count(*) from c);
+
+select id, w from q5c order by id;
+→ [{"id":2,"w":2}]
+
+-- ===== A MULTI-SOURCE view target sees them =====
+-- A join-bodied view decomposes into one base insert per member, each re-planned through
+-- this builder with a `preBuiltSource`. Every member must still carry the statement's CTEs
+-- (and the RETURNING built over the decomposition must too).
+
+create table q11a (id integer primary key, a text);
+create table q11b (id integer primary key, b text);
+create view vq11 as select q11a.id as id, q11a.a as a, q11b.b as b
+  from q11a join q11b on q11a.id = q11b.id;
+-- run
+
+with c as (select id, v from p) insert into vq11 select id, v, v from c;
+
+select id, a from q11a order by id;
+→ [{"id":1,"a":"a"},{"id":2,"a":"b"}]
+
+select id, b from q11b order by id;
+→ [{"id":1,"b":"a"},{"id":2,"b":"b"}]
+
+-- ===== An INSERT's own WITH clause does not hide the ones it INHERITED =====
+-- Arm B: the inner `with c as (…)` used to replace, rather than shadow into, the enclosing
+-- statement's definitions, so `a` vanished and the insert failed `Table 'a' not found`.
+
+create table q6 (id integer primary key, w integer);
+-- run
+
+with a as (select id from p),
+     b as (with c as (select 1 as k) insert into q6 select id + 40, (select k from c) from a returning id)
+select count(*) as n from b;
+→ [{"n":2}]
+
+select id, w from q6 order by id;
+→ [{"id":41,"w":1},{"id":42,"w":1}]
+
+-- ===== An own-clause name still SHADOWS a same-named inherited one =====
+
+create table q7 (id integer primary key, w integer);
+-- run
+
+with a as (select id from p),
+     b as (with a as (select 77 as id) insert into q7 select id, 5 from a returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+-- 77, not 1 and 2 — the inner `a` won.
+select id, w from q7 order by id;
+→ [{"id":77,"w":5}]
+
+-- ===== An INSERT nested in FROM / expression position inherits through the context =====
+-- These two shapes reach `buildInsertStmt` with no WITH clause of their own — the enclosing
+-- statement's definitions arrive only via `ctx.cteNodes`. Both only work because RETURNING
+-- is now built on the CTE-aware context rather than the bare one.
+
+create table q12 (id integer primary key, w integer);
+create table q13 (id integer primary key, w integer);
+-- run
+
+with c as (select id from p)
+select n from (insert into q12 values (1, 5) returning (select count(*) from c) as n) as d;
+→ [{"n":2}]
+
+with c as (select id from p)
+select (select n from (insert into q13 values (2, 6) returning (select count(*) from c) as n)) as k;
+→ [{"k":2}]
+
+-- ===== Control: the `select` source branch (the one that always worked) =====
+
+create table q8 (id integer primary key, w text);
+-- run
+
+with c as (select id, v from p) insert into q8 select id + 300, v from c;
+
+select id, w from q8 order by id;
+→ [{"id":301,"w":"a"},{"id":302,"w":"b"}]
+
+-- ===== Control: schema-authored DEFAULT expressions do NOT bind a caller's CTE =====
+-- A table's own DDL is not part of the user's statement, so the statement-level CTE
+-- context is deliberately withheld from column defaults / generated columns / CHECKs.
+-- `c` here is a real table, and the default must keep resolving to it even when the
+-- INSERT declares a CTE of the same name.
+
+create table c (k integer primary key);
+insert into c values (1), (2), (3);
+create table q9 (id integer primary key, w integer default (select count(*) from c));
+-- run
+
+with c as (select id from p) insert into q9 (id) values (9);
+
+-- 3 (the real table), not 2 (the CTE).
+select id, w from q9 order by id;
+→ [{"id":9,"w":3}]
+
+-- ===== ON CONFLICT and WITH CONTEXT: name resolution AND execution both work =====
+-- These two clauses RESOLVE the statement's CTEs (no more `Table 'c' not found`), and a
+-- subquery in either position now executes correctly — `DmlExecutorNode` exposes its
+-- ON CONFLICT / mutation-context expressions as optimizer-visible children, so their
+-- subquery subtrees get rewritten like any other child. Fixed by
+-- `bug-dml-side-expressions-invisible-to-optimizer`.
+
+create table q10 (id integer primary key, w text);
+insert into q10 values (1, 'x');
+create table mc (id integer primary key, v text) with context (who integer);
+-- run
+
+with c as (select id from p) insert into q10 values (1, 'x')
+  on conflict (id) do update set w = (select count(*) from c) returning w;
+→ [{"w":"2"}]
+
+with c as (select id from p) insert into q10 values (1, 'x')
+  on conflict (id) do update set w = 'y' where (select count(*) from c) > 0 returning w;
+→ [{"w":"y"}]
+
+with c as (select id from p) insert into mc with context who = (select count(*) from c)
+  values (1, 'x') returning v;
+→ [{"v":"x"}]
+
+-- The same three shapes work identically with NO leading WITH clause — the fix is
+-- not about CTE visibility.
+insert into q10 values (1, 'x') on conflict (id) do update set w = (select count(*) from p) returning w;
+→ [{"w":"2"}]
+
+insert into mc with context who = (select count(*) from p) values (2, 'x') returning id, v;
+→ [{"id":2,"v":"x"}]
+
+-- Cleanup
+-- q9's DEFAULT reads `c` through a subquery, so it has to go first: dropping a table a
+-- stored expression still names is refused (41.10.4-drop-object-expression-dependents).
+drop materialized view mvq4;
+drop view vq3;
+drop view vq11;
+drop table q9;
+drop table p;
+drop table c;
+drop table q1;
+drop table q2;
+drop table q3;
+drop table q4;
+drop table q5;
+drop table q5src;
+drop table q5b;
+drop table q5c;
+drop table q5upd;
+drop table q11a;
+drop table q11b;
+drop table q12;
+drop table q13;
+drop table q6;
+drop table q7;
+drop table q8;
+drop table q10;
+drop table mc;
+-- run

package/test/logic/13.9-schema-authored-cte-isolation.sqllogic

@@ -0,0 +1,328 @@
+-- 13.9-schema-authored-cte-isolation.sqllogic - a table's own DDL never binds a statement's CTEs
+--
+-- A column DEFAULT, a generated-column expression, a CHECK constraint and a foreign-key
+-- check are written in the TABLE's definition, not in the statement doing the write, so
+-- their unqualified relation names must always mean real schema objects. They used to be
+-- built on a planning context that still carried the statement's common-table-expression
+-- definitions, so a caller naming a CTE after a real table silently changed what someone
+-- else's DDL meant — a wrong stored value, or a spurious constraint failure.
+--
+-- Two flavours leak, and the DML builders differed in which reached them:
+--   * INHERITED — the definitions come from an ENCLOSING statement, arriving through
+--     `ctx.cteNodes` (all three builders);
+--   * OWN — the definitions come from the write statement's own leading `with` clause
+--     (UPDATE / DELETE only; INSERT's own clause was already kept out, pinned by
+--     13.8-insert-with-clause-visibility.sqllogic § "schema-authored DEFAULT expressions").
+-- `schemaAuthoredContext` (planner/building/schema-authored-context.ts) closes both.
+--
+-- Every arm below is written so the WRONG binding is observable: the caller's CTE and the
+-- real table disagree, and the assertion pins the real table's answer.
+
+pragma foreign_keys = true;
+
+-- `c` is a real table with 3 rows; `p` has 1 row, so a CTE `c` over `p` has 1 row.
+create table c (k integer primary key);
+insert into c values (1), (2), (3);
+create table p (id integer primary key);
+insert into p values (10);
+-- run
+
+-- ===== Column DEFAULT (inherited) =====
+
+create table sa_def (id integer primary key, w integer default (select count(*) from c));
+-- run
+
+with c as (select id from p),
+     b as (insert into sa_def (id) values (1) returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+-- 3 (the real table), not 1 (the caller's CTE over p).
+select id, w from sa_def order by id;
+→ [{"id":1,"w":3}]
+
+-- ===== Generated column (inherited) =====
+
+create table sa_gen (id integer primary key, g integer generated always as ((select count(*) from c)));
+-- run
+
+with c as (select id from p),
+     b as (insert into sa_gen (id) values (1) returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id, g from sa_gen order by id;
+→ [{"id":1,"g":3}]
+
+-- ===== CHECK on INSERT (inherited) =====
+-- The check holds against the real `c` (3 rows) and fails against the caller's (1 row),
+-- so a leak shows up as a spurious `CHECK constraint failed`.
+
+create table sa_cki (id integer primary key, check ((select count(*) from c) = 3));
+-- run
+
+with c as (select id from p),
+     b as (insert into sa_cki values (1) returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id from sa_cki order by id;
+→ [{"id":1}]
+
+-- The other direction: a check that the REAL table can never satisfy must not be rescued
+-- by a caller CTE that would satisfy it.
+
+create table sa_ckx (id integer primary key, check ((select count(*) from c) = 1));
+-- run
+
+with c as (select id from p),
+     b as (insert into sa_ckx values (1) returning id)
+select count(*) as n from b;
+-- error: CHECK
+
+select count(*) as n from sa_ckx;
+→ [{"n":0}]
+
+-- ===== CHECK on UPDATE =====
+
+create table sa_cku (id integer primary key, v integer, check ((select count(*) from c) = 3));
+insert into sa_cku values (1, 1);
+-- run
+
+-- (a) the UPDATE's OWN leading with clause
+with c as (select id from p) update sa_cku set v = 2 where id = 1;
+
+select id, v from sa_cku order by id;
+→ [{"id":1,"v":2}]
+
+-- (b) definitions INHERITED from an enclosing statement
+with c as (select id from p),
+     b as (update sa_cku set v = 3 where id = 1 returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id, v from sa_cku order by id;
+→ [{"id":1,"v":3}]
+
+-- ===== CHECK on DELETE =====
+
+create table sa_ckd (id integer primary key, v integer, check on delete ((select count(*) from c) = 3));
+insert into sa_ckd values (1, 1), (2, 2);
+-- run
+
+-- (a) the DELETE's OWN leading with clause
+with c as (select id from p) delete from sa_ckd where id = 1;
+
+select id, v from sa_ckd order by id;
+→ [{"id":2,"v":2}]
+
+-- (b) definitions INHERITED from an enclosing statement
+with c as (select id from p),
+     b as (delete from sa_ckd where id = 2 returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select count(*) as n from sa_ckd;
+→ [{"n":0}]
+
+-- ===== NOT NULL column DEFAULT (used by REPLACE substitution) =====
+-- `buildNotNullDefaults` pre-builds the DEFAULT evaluator the constraint runtime
+-- substitutes when REPLACE meets an explicit NULL. Same schema-authored surface.
+
+create table sa_nnd (id integer primary key, w integer not null default (select count(*) from c));
+-- run
+
+with c as (select id from p),
+     b as (insert or replace into sa_nnd (id, w) values (1, null) returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id, w from sa_nnd order by id;
+→ [{"id":1,"w":3}]
+
+-- ===== Child-side foreign key (INSERT) =====
+-- The synthesized probe is `exists (select 1 from main.<parent> where …)`. `buildFrom` used
+-- to match a CTE on the BARE table name and ignore the schema qualifier, so a caller
+-- `with fkp as (…)` won even against the schema-qualified synthesized FROM. Two independent
+-- fixes now close that: `schemaAuthoredContext` keeps the caller's CTEs out of this context
+-- at all, and `buildFrom` skips its CTE lookup for a qualified name
+-- (13.10-cte-qualified-name.sqllogic). The arms below still pin the behaviour.
+-- Here the real parent HAS the referenced row and the caller's CTE does not, so a leak
+-- shows up as a spurious `CHECK constraint failed: _fk_…`.
+
+create table fkp (id integer primary key);
+insert into fkp values (1);
+create table fkc (id integer primary key, pid integer references fkp(id));
+-- run
+
+-- (a) inherited
+with fkp as (select 99 as id),
+     b as (insert into fkc values (1, 1) returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id, pid from fkc order by id;
+→ [{"id":1,"pid":1}]
+
+-- (b) the INSERT's own leading with clause. This one already behaved before the fix —
+-- `buildInsertStmt` hands the FK builder the bare `ctx`, which never carried the
+-- statement's OWN clause — so it pins the contract rather than the closed leak.
+with fkp as (select 99 as id) insert into fkc values (2, 1);
+
+select id, pid from fkc order by id;
+→ [{"id":1,"pid":1},{"id":2,"pid":1}]
+
+-- ===== Child-side foreign key (UPDATE) =====
+
+create table fkc2 (id integer primary key, pid integer null references fkp(id));
+insert into fkc2 values (1, null);
+-- run
+
+with fkp as (select 99 as id),
+     b as (update fkc2 set pid = 1 where id = 1 returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id, pid from fkc2 order by id;
+→ [{"id":1,"pid":1}]
+
+-- ===== Parent-side RESTRICT foreign key (DELETE) =====
+-- The parent-side `not exists (select 1 from main.<child> where …)` probe is built only
+-- when the batched-RESTRICT gate declines, which a second inbound non-RESTRICT FK forces.
+-- The real child table is EMPTY (the delete is legal); the caller's CTE holds a matching
+-- row, so a leak shows up as a spurious rejection of a legal delete.
+
+create table pkp (id integer primary key);
+create table pkc (id integer primary key, pid integer references pkp(id) on delete restrict);
+create table pkc2 (id integer primary key, pid integer references pkp(id) on delete cascade);
+insert into pkp values (1), (2);
+-- run
+
+with pkc as (select 1 as pid),
+     b as (delete from pkp where id = 1 returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id from pkp order by id;
+→ [{"id":2}]
+
+-- The real RESTRICT is still enforced — a caller CTE must not disable it either.
+-- (The rejection comes from the plan-time `not exists` probe, whose diagnostic is the
+-- synthesized constraint's name rather than the runtime RESTRICT wording.)
+insert into pkc values (1, 2);
+-- run
+
+with pkc as (select 99 as pid) delete from pkp where id = 2;
+-- error: CHECK constraint failed: _fk_pkc_pid
+
+select id from pkp order by id;
+→ [{"id":2}]
+
+-- ===== Parent-side RESTRICT foreign key (UPDATE) =====
+
+create table qkp (id integer primary key);
+create table qkc (id integer primary key, pid integer references qkp(id) on update restrict);
+create table qkc2 (id integer primary key, pid integer references qkp(id) on update cascade);
+insert into qkp values (1);
+-- run
+
+with qkc as (select 1 as pid),
+     b as (update qkp set id = 5 where id = 1 returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id from qkp order by id;
+→ [{"id":5}]
+
+-- ===== View target: the base op re-planned through the same builders inherits the fix =====
+
+create table vsa_t (id integer primary key, w integer default (select count(*) from c));
+create view vsa AS select id, w from vsa_t;
+-- run
+
+with c as (select id from p) insert into vsa (id) values (1);
+
+select id, w from vsa_t order by id;
+→ [{"id":1,"w":3}]
+
+-- ===== Multi-source view INSERT: the anchor key column's declared DEFAULT =====
+-- The shared surrogate is minted ONCE per produced row at the envelope, from the anchor
+-- key column's own `default` — the one schema-authored expression the decomposition
+-- lowering builds itself rather than delegating to `buildInsertStmt`
+-- (`buildKeyDefault` in planner/building/view-mutation-builder.ts). A caller CTE named
+-- after the anchor used to change the high-water mark the allocator observed.
+
+create table kd_core (rid integer primary key default (coalesce((select max(rid) from kd_core), 0) + mutation_ordinal()), name text);
+create table kd_contact (rid integer primary key, email text);
+create view kd_v as select c.name as name, k.email as email
+  from kd_core c join kd_contact k on k.rid = c.rid;
+insert into kd_core values (100, 'seed');
+-- run
+
+with kd_core as (select 0 as rid) insert into kd_v (name, email) values ('Ada', 'ada@x.io');
+
+-- 101 (above the real high-water mark 100), not 1 (above the caller's CTE).
+select rid, name from kd_core order by rid;
+→ [{"rid":100,"name":"seed"},{"rid":101,"name":"Ada"}]
+
+select rid, email from kd_contact order by rid;
+→ [{"rid":101,"email":"ada@x.io"}]
+
+-- ===== Controls: the clearing reaches ONLY the schema-authored expressions =====
+-- (a) The statement that must NOT leak into the default still reads the CTE everywhere
+-- the user wrote it: the insert's source and its scalar subquery see `c` as the 1-row
+-- CTE (`v = 1`), while the column default sees the real 3-row table (`w = 3`).
+
+create table sa_both (id integer primary key, v integer, w integer default (select count(*) from c));
+-- run
+
+with c as (select id from p),
+     b as (insert into sa_both (id, v) select id, (select count(*) from c) from c returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id, v, w from sa_both order by id;
+→ [{"id":10,"v":1,"w":3}]
+
+-- (b) A schema-authored expression's OWN `with` clause still binds: the namespace is
+-- cleared on the way IN, not disabled, so a default may declare and read its own CTE —
+-- and a relation that clause reads is still the real table, not the caller's.
+
+create table sa_ownwith (id integer primary key, w integer default ((with q as (select count(*) as n from c) select n from q)));
+-- run
+
+with c as (select id from p),
+     b as (insert into sa_ownwith (id) values (1) returning id)
+select count(*) as n from b;
+→ [{"n":1}]
+
+select id, w from sa_ownwith order by id;
+→ [{"id":1,"w":3}]
+
+-- Cleanup
+drop table sa_ownwith;
+drop table sa_both;
+drop view kd_v;
+drop view vsa;
+drop table kd_contact;
+drop table kd_core;
+drop table vsa_t;
+drop table qkc2;
+drop table qkc;
+drop table qkp;
+drop table pkc2;
+drop table pkc;
+drop table pkp;
+drop table fkc2;
+drop table fkc;
+drop table fkp;
+drop table sa_nnd;
+drop table sa_ckd;
+drop table sa_cku;
+drop table sa_ckx;
+drop table sa_cki;
+drop table sa_gen;
+drop table sa_def;
+drop table p;
+drop table c;
+-- run