@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/10.1.2-ddl-in-transaction.sqllogic

@@ -0,0 +1,143 @@
+-- Row-validating DDL inside an open transaction.
+--
+-- `create unique index` and `alter table ... add constraint ... unique` must see the
+-- rows the issuing transaction has written but not yet committed, and the constraint
+-- they declare must stay enforced for the rest of that transaction.
+--
+-- Runs against every backend (memory, store). Each statement is its own block so an
+-- expected failure is attributed to exactly one statement.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- The `alter table ... add constraint ... unique` twins of §1 and §4 need no index DDL at all,
+-- so they live in 10.1.2.1-add-constraint-in-transaction and run on every backend. Everything
+-- left here builds the constraint through `create unique index`.
+
+-- ===================================
+-- 1. create unique index over rows the transaction just inserted
+-- ===================================
+
+create table ddl_tx_a (id integer primary key, v text);
+-- run
+begin;
+-- run
+insert into ddl_tx_a values (1, 'a');
+-- run
+insert into ddl_tx_a values (2, 'a');
+-- run
+create unique index ddl_tx_a_ix on ddl_tx_a (v);
+-- error: UNIQUE constraint failed
+rollback;
+-- run
+
+-- The rejected transaction left nothing behind.
+select count(*) as cnt from ddl_tx_a;
+→ [{ "cnt": 0 }]
+
+-- ===================================
+-- 2. create unique index over a pending row colliding with a committed one
+-- ===================================
+
+insert into ddl_tx_a values (1, 'a');
+-- run
+begin;
+-- run
+insert into ddl_tx_a values (2, 'a');
+-- run
+create unique index ddl_tx_a_ix on ddl_tx_a (v);
+-- error: UNIQUE constraint failed
+rollback;
+-- run
+
+select count(*) as cnt from ddl_tx_a;
+→ [{ "cnt": 1 }]
+
+-- ===================================
+-- 3. add constraint ... unique over rows the transaction just inserted
+-- ===================================
+-- Lives in 10.1.2.1-add-constraint-in-transaction § 1 (it needs no index DDL).
+
+-- ===================================
+-- 4. Accepted DDL enforces the new constraint for the rest of the transaction
+-- ===================================
+
+create table ddl_tx_c (id integer primary key, v text);
+-- run
+begin;
+-- run
+insert into ddl_tx_c values (1, 'a');
+-- run
+create unique index ddl_tx_c_ix on ddl_tx_c (v);
+-- run
+insert into ddl_tx_c values (2, 'a');
+-- error: UNIQUE constraint failed
+
+-- The transaction is still open; a non-colliding row is accepted and commits.
+insert into ddl_tx_c values (3, 'b');
+-- run
+commit;
+-- run
+
+select id, v from ddl_tx_c order by id;
+→ [{ "id": 1, "v": "a" }, { "id": 3, "v": "b" }]
+
+-- The committed index still enforces uniqueness.
+insert into ddl_tx_c values (4, 'b');
+-- error: UNIQUE constraint failed
+
+-- ===================================
+-- 5. Same, through add constraint ... unique
+-- ===================================
+-- Lives in 10.1.2.1-add-constraint-in-transaction § 2 (it needs no index DDL).
+
+-- ===================================
+-- 6. A pending DELETE removes a committed duplicate, so the build is legal
+-- ===================================
+
+create table ddl_tx_e (id integer primary key, v text);
+-- run
+insert into ddl_tx_e values (1, 'a');
+-- run
+insert into ddl_tx_e values (2, 'a');
+-- run
+begin;
+-- run
+delete from ddl_tx_e where id = 2;
+-- run
+create unique index ddl_tx_e_ix on ddl_tx_e (v);
+-- run
+commit;
+-- run
+
+select id, v from ddl_tx_e order by id;
+→ [{ "id": 1, "v": "a" }]
+
+-- ===================================
+-- 7. NULLs are distinct: multiple pending NULLs never block the build
+-- ===================================
+
+create table ddl_tx_f (id integer primary key, v text null);
+-- run
+begin;
+-- run
+insert into ddl_tx_f values (1, null);
+-- run
+insert into ddl_tx_f values (2, null);
+-- run
+create unique index ddl_tx_f_ix on ddl_tx_f (v);
+-- run
+commit;
+-- run
+
+select count(*) as cnt from ddl_tx_f;
+→ [{ "cnt": 2 }]
+
+-- Cleanup
+drop table ddl_tx_a;
+-- run
+drop table ddl_tx_c;
+-- run
+drop table ddl_tx_e;
+-- run
+drop table ddl_tx_f;
+-- run

package/test/logic/10.1.2.1-add-constraint-in-transaction.sqllogic

@@ -0,0 +1,59 @@
+-- Adding a UNIQUE constraint inside an open transaction must see the rows that transaction
+-- has written but not yet committed, and must stay enforced for the rest of it.
+--
+-- Carved out of 10.1.2-ddl-in-transaction, which is annotated
+-- `requires-capability: standalone-index-ddl` because its subject is `create unique index`.
+-- These two sections are the constraint-side twins of that file's § 1 and § 4 and use no
+-- index DDL, so a backend skipping 10.1.2 would have lost them for no reason.
+--
+-- Runs against every backend (memory, store). Each statement is its own block so an
+-- expected failure is attributed to exactly one statement.
+
+-- ===================================
+-- 1. add constraint ... unique over rows the transaction just inserted
+-- ===================================
+
+create table ddl_tx_b (id integer primary key, v text);
+-- run
+begin;
+-- run
+insert into ddl_tx_b values (1, 'a');
+-- run
+insert into ddl_tx_b values (2, 'a');
+-- run
+alter table ddl_tx_b add constraint ddl_tx_b_u unique (v);
+-- error: UNIQUE constraint failed
+rollback;
+-- run
+
+-- The rejected transaction left nothing behind.
+select count(*) as cnt from ddl_tx_b;
+→ [{ "cnt": 0 }]
+
+-- ===================================
+-- 2. An accepted add constraint enforces for the rest of the transaction
+-- ===================================
+
+create table ddl_tx_d (id integer primary key, v text);
+-- run
+begin;
+-- run
+insert into ddl_tx_d values (1, 'a');
+-- run
+alter table ddl_tx_d add constraint ddl_tx_d_u unique (v);
+-- run
+insert into ddl_tx_d values (2, 'a');
+-- error: UNIQUE constraint failed
+insert into ddl_tx_d values (3, 'b');
+-- run
+commit;
+-- run
+
+select id, v from ddl_tx_d order by id;
+→ [{ "id": 1, "v": "a" }, { "id": 3, "v": "b" }]
+
+-- Cleanup
+drop table ddl_tx_b;
+-- run
+drop table ddl_tx_d;
+-- run

package/test/logic/10.1.3-ddl-drop-in-transaction.sqllogic

@@ -0,0 +1,187 @@
+-- Dropping a UNIQUE index / constraint inside an open transaction must stop enforcing it
+-- for the rest of that transaction.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- A `TransactionLayer` freezes its schema at construction and enforces UNIQUE off that frozen
+-- schema, so a `drop index` / `alter table … drop constraint` that ran after the layer forked
+-- used to keep rejecting rows against a constraint that no longer exists. The manager now hands
+-- the post-drop schema to every open layer (`adoptSchemaOnOpenLayers` → `TransactionLayer.adoptSchema`,
+-- which now also removes the dropped index), so enforcement stops immediately.
+--
+-- § 4 additionally pins the savepoint interaction, which is cross-backend on both counts: a
+-- `rollback to savepoint` keeps every row staged BEFORE the savepoint, and does NOT undo the
+-- DROP itself (DDL is not transactional on either backend).
+--
+-- Runs against every backend (memory, store). Each statement is its own block so an expected
+-- failure is attributed to exactly one statement.
+
+-- ===================================
+-- 1. drop index on a unique index inside a transaction stops enforcing it
+-- ===================================
+
+create table drop_tx_a (id integer primary key, v text);
+-- run
+create unique index drop_tx_a_ix on drop_tx_a (v);
+-- run
+begin;
+-- run
+insert into drop_tx_a values (1, 'a');
+-- run
+drop index drop_tx_a_ix;
+-- run
+
+-- The unique index is gone, so a colliding row is now accepted mid-transaction.
+insert into drop_tx_a values (2, 'a');
+-- run
+commit;
+-- run
+
+select id, v from drop_tx_a order by id;
+→ [{ "id": 1, "v": "a" }, { "id": 2, "v": "a" }]
+
+-- After commit the constraint is genuinely gone: a fresh duplicate is still accepted.
+insert into drop_tx_a values (3, 'a');
+-- run
+
+select count(*) as cnt from drop_tx_a;
+→ [{ "cnt": 3 }]
+
+-- ===================================
+-- 2. alter table … drop constraint unique inside a transaction stops enforcing it
+-- ===================================
+-- The constraint-side twin of § 1 needs no index DDL, so it lives in
+-- 10.1.3.1-drop-constraint-in-transaction and stays runnable on backends that skip
+-- this file.
+
+-- ===================================
+-- 3. Dropping one unique index leaves a sibling unique index still enforced
+-- ===================================
+
+create table drop_tx_c (id integer primary key, v text, w text);
+-- run
+create unique index drop_tx_c_v on drop_tx_c (v);
+-- run
+create unique index drop_tx_c_w on drop_tx_c (w);
+-- run
+begin;
+-- run
+insert into drop_tx_c values (1, 'a', 'x');
+-- run
+drop index drop_tx_c_v;
+-- run
+
+-- The dropped index no longer blocks a duplicate v.
+insert into drop_tx_c values (2, 'a', 'y');
+-- run
+
+-- The sibling index on w is untouched and still rejects a duplicate w.
+insert into drop_tx_c values (3, 'b', 'x');
+-- error: UNIQUE constraint failed
+commit;
+-- run
+
+select id, v, w from drop_tx_c order by id;
+→ [{ "id": 1, "v": "a", "w": "x" }, { "id": 2, "v": "a", "w": "y" }]
+
+-- ===================================
+-- 4. index DDL inside a savepoint must not discard writes staged BEFORE the savepoint
+-- ===================================
+-- `rollback to savepoint s` unwinds only what happened after `s`. The isolation layer used to
+-- throw its staging overlay away and copy the staged rows into a fresh one on CREATE/DROP INDEX;
+-- the copy's first write lazily registered a connection, which replays the active savepoint
+-- stack BEFORE the copy — so every copied row landed above `s` and was discarded here. Silent
+-- data loss (bug-isolation-index-ddl-rebuild-drops-savepoint-writes).
+
+create table drop_sp_a (id integer primary key, v text);
+-- run
+create unique index drop_sp_a_ix on drop_sp_a (v);
+-- run
+begin;
+-- run
+insert into drop_sp_a values (1, 'a');
+-- run
+savepoint s;
+-- run
+
+-- Staged AFTER the savepoint: these two must go.
+insert into drop_sp_a values (2, 'b');
+-- run
+drop index drop_sp_a_ix;
+-- run
+insert into drop_sp_a values (3, 'c');
+-- run
+rollback to savepoint s;
+-- run
+
+-- Pre-savepoint row kept, post-savepoint rows discarded — both directions.
+select id, v from drop_sp_a order by id;
+→ [{ "id": 1, "v": "a" }]
+
+-- DDL is not transactional on either backend, so `rollback to savepoint` does NOT undo the
+-- DROP: a would-be duplicate is still accepted. Making DDL reversible belongs to the larger
+-- feature `feat-ddl-transaction-capability`.
+insert into drop_sp_a values (4, 'a');
+-- run
+commit;
+-- run
+
+select id, v from drop_sp_a order by id;
+→ [{ "id": 1, "v": "a" }, { "id": 4, "v": "a" }]
+
+-- Same for the additive direction: CREATE INDEX under a savepoint.
+create table drop_sp_b (id integer primary key, v text);
+-- run
+begin;
+-- run
+insert into drop_sp_b values (1, 'a');
+-- run
+savepoint s2;
+-- run
+create unique index drop_sp_b_ix on drop_sp_b (v);
+-- run
+rollback to savepoint s2;
+-- run
+
+select id, v from drop_sp_b order by id;
+→ [{ "id": 1, "v": "a" }]
+commit;
+-- run
+
+select id, v from drop_sp_b order by id;
+→ [{ "id": 1, "v": "a" }]
+
+-- A tombstone staged before the savepoint survives the DDL too: the DELETE still lands.
+create table drop_sp_c (id integer primary key, v text);
+-- run
+insert into drop_sp_c values (1, 'a'), (2, 'b');
+-- run
+create unique index drop_sp_c_ix on drop_sp_c (v);
+-- run
+begin;
+-- run
+delete from drop_sp_c where id = 1;
+-- run
+savepoint s3;
+-- run
+drop index drop_sp_c_ix;
+-- run
+rollback to savepoint s3;
+-- run
+commit;
+-- run
+
+select id, v from drop_sp_c order by id;
+→ [{ "id": 2, "v": "b" }]
+
+-- Cleanup
+drop table drop_tx_a;
+-- run
+drop table drop_tx_c;
+-- run
+drop table drop_sp_a;
+-- run
+drop table drop_sp_b;
+-- run
+drop table drop_sp_c;
+-- run

package/test/logic/10.1.3.1-drop-constraint-in-transaction.sqllogic

@@ -0,0 +1,45 @@
+-- Dropping a UNIQUE constraint inside an open transaction must stop enforcing it for the
+-- rest of that transaction.
+--
+-- Carved out of 10.1.3-ddl-drop-in-transaction, which is annotated
+-- `requires-capability: standalone-index-ddl` because most of it drops UNIQUE INDEXES.
+-- This section is the constraint-side twin of that file's § 1 and uses no index DDL, so a
+-- backend skipping 10.1.3 would have lost it for no reason.
+--
+-- A `TransactionLayer` freezes its schema at construction and enforces UNIQUE off that frozen
+-- schema, so an `alter table … drop constraint` that ran after the layer forked used to keep
+-- rejecting rows against a constraint that no longer exists. The manager now hands the
+-- post-drop schema to every open layer (`adoptSchemaOnOpenLayers` → `TransactionLayer.adoptSchema`),
+-- so enforcement stops immediately.
+--
+-- Runs against every backend (memory, store). Each statement is its own block so an expected
+-- failure is attributed to exactly one statement.
+
+-- ===================================
+-- alter table … drop constraint unique inside a transaction stops enforcing it
+-- ===================================
+
+create table drop_tx_b (id integer primary key, v text, constraint drop_tx_b_u unique (v));
+-- run
+begin;
+-- run
+insert into drop_tx_b values (1, 'a');
+-- run
+alter table drop_tx_b drop constraint drop_tx_b_u;
+-- run
+
+-- The unique constraint is gone, so a colliding row is now accepted mid-transaction.
+insert into drop_tx_b values (2, 'a');
+-- run
+commit;
+-- run
+
+select id, v from drop_tx_b order by id;
+→ [{ "id": 1, "v": "a" }, { "id": 2, "v": "a" }]
+
+-- After commit the constraint is genuinely gone: a fresh duplicate is still accepted.
+insert into drop_tx_b values (3, 'a');
+-- run
+
+select count(*) as cnt from drop_tx_b;
+→ [{ "cnt": 3 }]

package/test/logic/10.1.4-create-table-duplicate-constraint-names.sqllogic

@@ -0,0 +1,149 @@
+-- CREATE TABLE constraint-name uniqueness and minted-name disambiguation.
+--
+-- One constraint name must address exactly one constraint on a table. Two arms:
+--
+--   1. USER-WRITTEN names: a CREATE TABLE declaring two constraints under one
+--      (case-folded) name is refused outright — the same within-table rule every
+--      ALTER path enforces via assertConstraintNameFree, applied at birth
+--      (assertNoDuplicateConstraintNames, schema/catalog.ts). One name space
+--      across CHECK / UNIQUE / FOREIGN KEY: a same-class collision makes DROP
+--      CONSTRAINT remove both, and a cross-class collision is permanently
+--      un-droppable (resolveNamedConstraintClass reports it ambiguous forever).
+--
+--   2. ENGINE-MINTED names (`_check_<col>`, `_fk_<table>_<cols>`): the colliding
+--      declaration is LEGAL (two unnamed CHECKs on one column; two FKs on one
+--      child column into different parents), so the mint disambiguates instead of
+--      rejecting: the first occurrence keeps the base name, the Nth gets `_<N>`
+--      (disambiguateAutoConstraintName, schema/table.ts). Every non-colliding
+--      mint stays byte-identical to before — 41.10.3 and 03.4 pin that.
+--
+-- No `-- requires-capability:` directive, so this runs under both the memory
+-- module and the store module. The store leg matters: disambiguated names are
+-- persisted and must survive a reopen.
+
+pragma foreign_keys = true;
+
+-- ===================================================================
+-- 1. User-written duplicate names are refused at CREATE TABLE
+-- ===================================================================
+
+-- 1a. Exact duplicate, same class.
+create table Dup1 (id integer primary key, a integer, b integer, constraint z unique (a), constraint z unique (b));
+-- error: duplicate constraint name 'z'
+
+-- 1b. Case-differing spellings are one name (identifier semantics).
+create table Dup2 (id integer primary key, a integer, b integer, constraint q unique (a), constraint Q unique (b));
+-- error: duplicate constraint name
+
+-- 1c. Cross-class (UNIQUE vs FOREIGN KEY) — the un-droppable-forever shape.
+create table NPar (pid integer primary key, r integer unique);
+create table Dup3 (id integer primary key, a integer, constraint n unique (a), constraint n foreign key (a) references NPar(r));
+-- error: duplicate constraint name 'n'
+
+-- 1d. Cross-class (CHECK vs UNIQUE), column-level vs table-level declaration.
+create table Dup4 (id integer primary key, a integer constraint w check (a > 0), constraint W unique (a));
+-- error: duplicate constraint name
+
+-- None of the refused tables were created.
+select count(*) as c from schema() where type = 'table' and name like 'Dup%';
+→ [{"c":0}]
+
+-- Distinct names on the same shapes are accepted (positive control).
+create table DOk (id integer primary key, a integer, b integer, constraint u1 unique (a), constraint u2 unique (b));
+drop table DOk;
+
+-- ===================================================================
+-- 2. Two unnamed FKs on one child column (different parents): minted
+--    `_fk_FkC_x` and `_fk_FkC_x_2`, each addressable, each dropping only itself
+-- ===================================================================
+
+create table FkP1 (x integer primary key);
+create table FkP2 (y integer primary key);
+create table FkC (id integer primary key, x integer null, foreign key (x) references FkP1(x), foreign key (x) references FkP2(y));
+
+select name, "to" from foreign_key_info('FkC') order by name;
+→ [{"name":"_fk_FkC_x","to":"x"},{"name":"_fk_FkC_x_2","to":"y"}]
+
+-- Both keys enforce, each under its own name (FK existence checks share the
+-- `CHECK constraint failed:` prefix — see runtime/row-constraints.ts).
+-- A value present in FkP1 but not FkP2 trips only the second key…
+insert into FkP1 values (1);
+insert into FkC values (1, 1);
+-- error: CHECK constraint failed: _fk_FkC_x_2
+
+-- …a value present in FkP2 but not FkP1 trips only the first…
+insert into FkP2 values (2);
+insert into FkC values (1, 2);
+-- error: CHECK constraint failed: _fk_FkC_x
+
+-- …and a value present in both parents is accepted.
+insert into FkP2 values (7);
+insert into FkP1 values (7);
+insert into FkC values (1, 7);
+select count(*) as c from FkC;
+→ [{"c":1}]
+
+-- Dropping the first key removes ONLY it (the original defect removed both).
+alter table FkC drop constraint _fk_FkC_x;
+select name from foreign_key_info('FkC');
+→ [{"name":"_fk_FkC_x_2"}]
+
+-- The surviving key still enforces (1 ∉ FkP2)…
+insert into FkC values (2, 1);
+-- error: CHECK constraint failed: _fk_FkC_x_2
+
+-- …while a value only FkP2 holds is now accepted (the dropped key no longer binds).
+insert into FkP2 values (9);
+insert into FkC values (3, 9);
+select count(*) as c from FkC;
+→ [{"c":2}]
+
+-- And the survivor is itself addressable by its disambiguated name.
+alter table FkC drop constraint _fk_FkC_x_2;
+select count(*) as c from foreign_key_info('FkC');
+→ [{"c":0}]
+insert into FkC values (4, 12345);
+select count(*) as c from FkC;
+→ [{"c":3}]
+
+-- ===================================================================
+-- 3. Two unnamed CHECKs on one column: minted `_check_b` and `_check_b_2`,
+--    both enforced, each individually droppable
+-- ===================================================================
+
+create table Ck (id integer primary key, b integer null check (b > 0) check (b < 10));
+insert into Ck values (1, 5);
+
+insert into Ck values (2, -1);
+-- error: _check_b (b > 0)
+
+insert into Ck values (2, 99);
+-- error: _check_b_2 (b < 10)
+
+-- Dropping `_check_b` removes only the lower bound; the upper bound survives.
+alter table Ck drop constraint _check_b;
+insert into Ck values (3, -1);
+insert into Ck values (4, 99);
+-- error: _check_b_2 (b < 10)
+
+alter table Ck drop constraint _check_b_2;
+insert into Ck values (5, 99);
+select count(*) as c from Ck;
+→ [{"c":3}]
+
+-- ===================================================================
+-- 4. A mint never collides with a name the user typed: the user claims
+--    `_check_b`, so the unnamed CHECK on the same column mints `_check_b_2`
+-- ===================================================================
+
+create table MintU (id integer primary key, b integer null constraint _check_b check (b < 10) check (b > 0));
+insert into MintU values (1, -1);
+-- error: _check_b_2 (b > 0)
+
+-- ===================================================================
+-- 5. A non-colliding mint is unchanged (pins the compatibility property)
+-- ===================================================================
+
+create table Solo (id integer primary key, b integer null check (b > 0));
+insert into Solo values (1, -1);
+-- error: _check_b (b > 0)