@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.8.1-alter-rename-savepoint-staged-rows.sqllogic

@@ -0,0 +1,408 @@
+-- `ALTER TABLE ... RENAME TO` inside a transaction that also holds a savepoint must not
+-- disturb the rows the transaction has already staged. Companion to
+-- 41.8-alter-savepoint-staged-rows, which covers the column-shape arms (ADD / DROP / RENAME
+-- COLUMN); this file covers the whole-table rename, which used to lose staged rows outright.
+--
+-- Two mechanisms were at fault, and the cases below exercise both:
+--
+--   1. `renameTable` minted a new frozen TableSchema but never handed it to the open
+--      transaction's layers, so an eager savepoint snapshot kept its pre-rename schema
+--      object, failed `commitTransaction`'s snapshot-wrap identity check, and COMMIT
+--      reported success having published nothing (cases B, C, F, G, H, K).
+--   2. the Database connection registry stayed keyed on the OLD qualified name, so every
+--      by-name lookup the renamed table's manager makes found nothing — and a second ALTER
+--      in the same transaction was refused with "another connection has uncommitted
+--      changes" (cases L, M, N).
+--
+-- A savepoint gets involved far more often than the SQL suggests: the DML executor takes
+-- internal savepoints for statement- and row-level rollback, so this is reachable without
+-- writing `savepoint` at all.
+
+-- Case A (control): savepoint with no ALTER at all — the pre-savepoint row survives.
+create table ca (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into ca values (1, 'a');
+-- run
+savepoint s;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from ca order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table ca;
+-- run
+
+-- Case B: insert; savepoint; rename; rollback to savepoint. The rename is DDL and escapes
+-- the rollback (the table stays renamed); the pre-savepoint row must still commit.
+create table cb (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cb values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table cb rename to cb2;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from cb2 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table cb2;
+-- run
+
+-- Case C: the same shape, released rather than rolled back.
+create table cc (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cc values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table cc rename to cc2;
+-- run
+release savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from cc2 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table cc2;
+-- run
+
+-- Case D (control): the DROP COLUMN twin of case B, which already worked — kept here so a
+-- regression in the shared adopt path shows up next to the rename cases.
+create table cd (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cd values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table cd drop column v;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id from cd order by id;
+→ [{"id":1}]
+
+drop table cd;
+-- run
+
+-- Case E (control): rename with NO savepoint anywhere. Always worked — the connection holds
+-- a pending layer, so the snapshot-wrap path is never reached.
+create table ce (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into ce values (1, 'a');
+-- run
+alter table ce rename to ce2;
+-- run
+commit;
+-- run
+
+select id, v from ce2 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table ce2;
+-- run
+
+-- Case F: savepoint taken AFTER the rename, then rolled back. The row was staged before
+-- both, so it survives.
+create table cf (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cf values (1, 'a');
+-- run
+alter table cf rename to cf2;
+-- run
+savepoint s;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from cf2 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table cf2;
+-- run
+
+-- Case G: savepoint after the rename, released.
+create table cg (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cg values (1, 'a');
+-- run
+alter table cg rename to cg2;
+-- run
+savepoint s;
+-- run
+release savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from cg2 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table cg2;
+-- run
+
+-- Case H: savepoint after the rename, left OPEN through COMMIT (the commit resolves it).
+create table ch (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into ch values (1, 'a');
+-- run
+alter table ch rename to ch2;
+-- run
+savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from ch2 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table ch2;
+-- run
+
+-- Case I: rename FIRST, then stage the row, then a savepoint above it.
+create table ci (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+alter table ci rename to ci2;
+-- run
+insert into ci2 values (1, 'a');
+-- run
+savepoint s;
+-- run
+release savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from ci2 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table ci2;
+-- run
+
+-- Case K: two renames in one transaction with a savepoint between them — each rename has to
+-- re-key the registry AND adopt its schema, or the second one loses the first one's work.
+create table ck (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into ck values (1, 'a');
+-- run
+alter table ck rename to ck2;
+-- run
+savepoint s;
+-- run
+alter table ck2 rename to ck3;
+-- run
+release savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from ck3 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table ck3;
+-- run
+
+-- Case L: rename followed by a CONSOLIDATING alter (ADD COLUMN) in the same transaction.
+-- This is the connection-registry defect: with the registry stale the transaction's own
+-- connection looked like a stranger holding uncommitted work and the ADD COLUMN was refused
+-- with BUSY. The staged row must survive and be backfilled.
+create table cl (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cl values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table cl rename to cl2;
+-- run
+alter table cl2 add column w text default 'x';
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v, w from cl2 order by id;
+→ [{"id":1,"v":"a","w":"x"}]
+
+drop table cl2;
+-- run
+
+-- Case M: rename then DROP COLUMN — the narrowing flavor of case L.
+create table cm (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cm values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table cm rename to cm2;
+-- run
+alter table cm2 drop column v;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id from cm2 order by id;
+→ [{"id":1}]
+
+drop table cm2;
+-- run
+
+-- Case N: the same pair in the other order — DROP COLUMN then rename.
+create table cn (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cn values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table cn drop column v;
+-- run
+alter table cn rename to cn2;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id from cn2 order by id;
+→ [{"id":1}]
+
+drop table cn2;
+-- run
+
+-- Case O (negative control): the insert happens AFTER the savepoint, so the rollback must
+-- still discard it. The fix must not resurrect rows the ledger says are gone.
+create table co (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+alter table co rename to co2;
+-- run
+savepoint s;
+-- run
+insert into co2 values (1, 'a');
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from co2 order by id;
+→ []
+
+drop table co2;
+-- run
+
+-- Case P (negative control): a full ROLLBACK, not `rollback to savepoint`. The rename is DDL
+-- and escapes the rollback, but every staged row must still be discarded — the adopt must not
+-- turn an abandoned transaction into a published one.
+create table cp (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cp values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table cp rename to cp2;
+-- run
+rollback;
+-- run
+
+select id, v from cp2 order by id;
+→ []
+
+drop table cp2;
+-- run
+
+-- Case Q: the transaction keeps READING and WRITING after the rename + savepoint rollback.
+-- Every case above only checks the post-COMMIT state, so nothing would catch an adopt that
+-- published the right rows while leaving the transaction's own mid-flight view wrong.
+create table cq (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into cq values (1, 'a');
+-- run
+savepoint s;
+-- run
+insert into cq values (2, 'b');
+-- run
+alter table cq rename to cq2;
+-- run
+rollback to savepoint s;
+-- run
+
+-- mid-transaction: the pre-savepoint row is visible under the new name, the post-savepoint
+-- row is not
+select id, v from cq2 order by id;
+→ [{"id":1,"v":"a"}]
+
+insert into cq2 values (3, 'c');
+-- run
+commit;
+-- run
+
+select id, v from cq2 order by id;
+→ [{"id":1,"v":"a"},{"id":3,"v":"c"}]
+
+drop table cq2;
+-- run

package/test/logic/41.9-alter-constraint-body-change.sqllogic

@@ -0,0 +1,180 @@
+-- 41.9-alter-constraint-body-change.sqllogic
+-- Declarative differ: a named constraint whose NAME is unchanged but whose BODY
+-- changed is realized as DROP CONSTRAINT + ADD CONSTRAINT (drop+recreate). The
+-- re-add re-validates existing rows for UNIQUE / FOREIGN KEY (fails atomically on
+-- a violation); CHECK is forward-enforcing only (its ADD does not re-validate
+-- existing rows — a pre-existing limitation of the CHECK add path). Behavioral
+-- assertions through `apply schema`, so this passes under both `yarn test`
+-- (memory) and `yarn test:store`.
+
+pragma foreign_keys = true;
+-- run
+
+-- ============================================================
+-- 1. CHECK body change → drop+recreate; new predicate enforced forward
+-- ============================================================
+declare schema main {
+	table tc { id integer primary key, qty integer, constraint chk check (qty > 0) }
+}
+apply schema main;
+insert into tc values (1, 5);
+-- run
+
+-- old body (qty > 0): qty = 0 rejected
+insert into tc values (2, 0);
+-- error: check
+
+-- widen the body to qty >= 0 (same constraint name)
+declare schema main {
+	table tc { id integer primary key, qty integer, constraint chk check (qty >= 0) }
+}
+apply schema main;
+-- run
+
+-- new body enforced: qty = 0 now accepted
+insert into tc values (2, 0);
+select count(*) as n from tc;
+→ [{"n":2}]
+
+-- new body still rejects qty < 0
+insert into tc values (3, -1);
+-- error: check
+
+-- re-applying the identical declaration is a no-op (canonical bodies match)
+diff schema main;
+→ []
+
+drop table tc;
+-- run
+
+-- ============================================================
+-- 2. UNIQUE body change (column set widened) → drop+recreate; converges
+-- ============================================================
+declare schema main {
+	table tu { id integer primary key, a integer, b integer, constraint uq unique (a) }
+}
+apply schema main;
+insert into tu values (1, 10, 100);
+-- run
+
+-- old body unique(a): duplicate a rejected
+insert into tu values (2, 10, 200);
+-- error: unique
+
+-- widen to unique(a, b)
+declare schema main {
+	table tu { id integer primary key, a integer, b integer, constraint uq unique (a, b) }
+}
+apply schema main;
+-- run
+
+-- new body unique(a,b): duplicate a with distinct b now accepted
+insert into tu values (2, 10, 200);
+select count(*) as n from tu;
+→ [{"n":2}]
+
+-- full (a,b) duplicate still rejected
+insert into tu values (3, 10, 100);
+-- error: unique
+
+diff schema main;
+→ []
+
+drop table tu;
+-- run
+
+-- ============================================================
+-- 3. UNIQUE body change the existing data VIOLATES → the re-add aborts the apply
+-- ============================================================
+-- NOTE: a body change is DROP + ADD (two statements). A multi-statement migration
+-- is not atomic for schema mutations on the memory backend, so a failed re-add can
+-- leave the old constraint dropped — we assert only that the apply aborts and the
+-- data remains queryable, not that the prior constraint is restored.
+declare schema main {
+	table tv { id integer primary key, a integer, b integer, constraint uq unique (a, b) }
+}
+apply schema main;
+-- distinct on (a,b), duplicated on a alone
+insert into tv values (1, 10, 100), (2, 10, 200);
+-- run
+
+-- narrow to unique(a): existing a=10 twice → re-validation fails on the re-add
+declare schema main {
+	table tv { id integer primary key, a integer, b integer, constraint uq unique (a) }
+}
+-- run
+
+apply schema main;
+-- error:
+
+-- the existing rows survive and a new distinct-on-(a,b) row is accepted
+insert into tv values (3, 10, 300);
+select count(*) as n from tv;
+→ [{"n":3}]
+
+drop table tv;
+-- run
+
+-- ============================================================
+-- 4. FOREIGN KEY body change (ON DELETE action) → drop+recreate; behavior changes
+-- ============================================================
+declare schema main {
+	table fkp { pid integer primary key }
+	table fkc { id integer primary key, pa integer, constraint fk foreign key (pa) references fkp(pid) on delete restrict }
+}
+apply schema main;
+insert into fkp values (1);
+insert into fkc values (10, 1);
+-- run
+
+-- old body (on delete restrict): deleting a referenced parent is blocked
+delete from fkp where pid = 1;
+-- error:
+
+-- change the action to ON DELETE CASCADE
+declare schema main {
+	table fkp { pid integer primary key }
+	table fkc { id integer primary key, pa integer, constraint fk foreign key (pa) references fkp(pid) on delete cascade }
+}
+apply schema main;
+-- run
+
+-- new body (on delete cascade): deleting the parent removes the child too
+delete from fkp where pid = 1;
+select count(*) as n from fkc;
+→ [{"n":0}]
+
+diff schema main;
+→ []
+
+drop table fkc;
+drop table fkp;
+-- run
+
+-- ============================================================
+-- 5. Disambiguation — a tag-only change takes SET TAGS, NOT a drop+recreate
+-- ============================================================
+declare schema main {
+	table tt { id integer primary key, a integer, constraint uq unique (a) with tags (msg = 'orig') }
+}
+apply schema main;
+-- run
+
+-- change only the constraint's tags (body identical)
+declare schema main {
+	table tt { id integer primary key, a integer, constraint uq unique (a) with tags (msg = 'updated') }
+}
+-- run
+
+-- the diff is a single in-place SET TAGS — no DROP/ADD CONSTRAINT
+diff schema main;
+→ [{"ddl": "ALTER TABLE tt ALTER CONSTRAINT uq SET TAGS (msg = 'updated')"}]
+
+apply schema main;
+-- run
+
+diff schema main;
+→ []
+
+drop table tt;
+-- run