@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.8-alter-add-constraint-unique-fk.sqllogic

@@ -0,0 +1,275 @@
+-- 41.8-alter-add-constraint-unique-fk.sqllogic
+-- ALTER TABLE ADD CONSTRAINT for table-level UNIQUE / FOREIGN KEY. The module
+-- re-validates the existing rows and fails atomically with CONSTRAINT when the
+-- current data violates the new constraint; otherwise it installs forward
+-- enforcement. Behavioral assertions only (enforcement + introspection via the
+-- *_constraint_info / *_info TVFs), so this runs identically under `yarn test`
+-- (memory) and `yarn test:store`.
+
+pragma foreign_keys = true;
+-- run
+
+-- ============================================================
+-- 1. ADD UNIQUE over conforming data — enforces going forward
+-- ============================================================
+create table u_ok (id integer primary key, email text);
+insert into u_ok values (1, 'a@x'), (2, 'b@x');
+-- run
+
+alter table u_ok add constraint uq_email unique (email);
+-- run
+
+-- introspection lists the named UNIQUE
+select name from unique_constraint_info('u_ok') where name = 'uq_email';
+→ [{"name":"uq_email"}]
+
+-- forward enforcement: a duplicate is rejected
+insert into u_ok values (3, 'a@x');
+-- error: unique
+
+-- a fresh value still inserts
+insert into u_ok values (3, 'c@x');
+select count(*) as c from u_ok;
+→ [{"c":3}]
+
+drop table u_ok;
+-- run
+
+-- ============================================================
+-- 2. ADD UNIQUE over duplicated existing data — rejected atomically
+-- ============================================================
+create table u_dup (id integer primary key, email text);
+insert into u_dup values (1, 'a@x'), (2, 'a@x');
+-- run
+
+-- the add fails because existing rows already violate uniqueness
+alter table u_dup add constraint uq_email unique (email);
+-- error: unique
+
+-- constraint NOT installed: it is absent from introspection
+select count(*) as c from unique_constraint_info('u_dup') where name = 'uq_email';
+→ [{"c":0}]
+
+-- ...and enforcement is not active: another duplicate inserts freely
+insert into u_dup values (3, 'a@x');
+select count(*) as c from u_dup;
+→ [{"c":3}]
+
+-- retry after removing the offending rows ⇒ the same ADD now converges. (Exercises the
+-- DELETE-after-schema-change consolidation path: the base primary tree is replaced, not unioned,
+-- so the deleted duplicates do not resurface in the UNIQUE index build.)
+delete from u_dup where id in (2, 3);
+alter table u_dup add constraint uq_email unique (email);
+-- run
+
+select count(*) as c from unique_constraint_info('u_dup') where name = 'uq_email';
+→ [{"c":1}]
+
+-- forward enforcement is now active under the retried constraint
+insert into u_dup values (4, 'a@x');
+-- error: unique
+
+drop table u_dup;
+-- run
+
+-- ============================================================
+-- 3. ADD UNIQUE with existing NULLs — multiple NULLs allowed
+-- ============================================================
+create table u_null (id integer primary key, email text null);
+insert into u_null values (1, null), (2, null);
+-- run
+
+-- two existing NULLs are distinct under SQL UNIQUE — the add succeeds
+alter table u_null add constraint uq_email unique (email);
+-- run
+
+-- further NULLs remain allowed
+insert into u_null values (3, null);
+select count(*) as c from u_null where email is null;
+→ [{"c":3}]
+
+drop table u_null;
+-- run
+
+-- ============================================================
+-- 4. Unnamed ADD UNIQUE (...) form (auto-named)
+-- ============================================================
+create table u_anon (id integer primary key, email text);
+insert into u_anon values (1, 'a@x');
+-- run
+
+alter table u_anon add unique (email);
+-- run
+
+insert into u_anon values (2, 'a@x');
+-- error: unique
+
+drop table u_anon;
+-- run
+
+-- ============================================================
+-- 5. ADD FOREIGN KEY over satisfied data — enforces going forward
+-- ============================================================
+create table fk_parent (pid integer primary key);
+insert into fk_parent values (1), (2);
+create table fk_child (id integer primary key, pa integer);
+insert into fk_child values (1, 1), (2, 2);
+-- run
+
+alter table fk_child add constraint fk_pa foreign key (pa) references fk_parent(pid);
+-- run
+
+select name from foreign_key_info('fk_child') where name = 'fk_pa';
+→ [{"name":"fk_pa"}]
+
+-- forward enforcement: an orphan child is rejected
+insert into fk_child values (3, 99);
+-- error:
+
+-- a satisfied child still inserts
+insert into fk_child values (3, 2);
+select count(*) as c from fk_child;
+→ [{"c":3}]
+
+drop table fk_child;
+drop table fk_parent;
+-- run
+
+-- ============================================================
+-- 6. ADD FOREIGN KEY over an orphaned row — rejected atomically
+-- ============================================================
+create table fk_parent (pid integer primary key);
+insert into fk_parent values (1);
+create table fk_child (id integer primary key, pa integer);
+insert into fk_child values (1, 1), (2, 99);
+-- run
+
+-- existing row (2, 99) has no parent → the add fails
+alter table fk_child add constraint fk_pa foreign key (pa) references fk_parent(pid);
+-- error:
+
+-- constraint NOT installed: absent from introspection
+select count(*) as c from foreign_key_info('fk_child') where name = 'fk_pa';
+→ [{"c":0}]
+
+-- ...and not enforced: another orphan inserts freely
+insert into fk_child values (3, 77);
+select count(*) as c from fk_child;
+→ [{"c":3}]
+
+drop table fk_child;
+drop table fk_parent;
+-- run
+
+-- ============================================================
+-- 7. ADD FOREIGN KEY with a NULL FK child (MATCH SIMPLE)
+-- ============================================================
+create table fk_parent (pid integer primary key);
+insert into fk_parent values (1);
+create table fk_child (id integer primary key, pa integer null);
+insert into fk_child values (1, null), (2, 1);
+-- run
+
+-- a NULL FK row is exempt (MATCH SIMPLE) — the add succeeds
+alter table fk_child add constraint fk_pa foreign key (pa) references fk_parent(pid);
+-- run
+
+-- further NULL FK rows remain allowed
+insert into fk_child values (3, null);
+-- run
+
+-- but a non-NULL orphan is rejected
+insert into fk_child values (4, 99);
+-- error:
+
+drop table fk_child;
+drop table fk_parent;
+-- run
+
+-- ============================================================
+-- 8. ADD FOREIGN KEY with pragma foreign_keys = false — no validation
+-- ============================================================
+pragma foreign_keys = false;
+create table fk_parent (pid integer primary key);
+insert into fk_parent values (1);
+create table fk_child (id integer primary key, pa integer);
+insert into fk_child values (1, 99);
+-- run
+
+-- pragma off: the orphan is NOT validated, so the add succeeds
+alter table fk_child add constraint fk_pa foreign key (pa) references fk_parent(pid);
+-- run
+
+select count(*) as c from foreign_key_info('fk_child') where name = 'fk_pa';
+→ [{"c":1}]
+
+drop table fk_child;
+drop table fk_parent;
+pragma foreign_keys = true;
+-- run
+
+-- ============================================================
+-- 9. Unnamed ADD FOREIGN KEY (...) form (auto-named)
+-- ============================================================
+create table fk_parent (pid integer primary key);
+insert into fk_parent values (1);
+create table fk_child (id integer primary key, pa integer);
+insert into fk_child values (1, 1);
+-- run
+
+alter table fk_child add foreign key (pa) references fk_parent(pid);
+-- run
+
+-- forward enforcement is active under the auto-name
+insert into fk_child values (2, 99);
+-- error:
+
+drop table fk_child;
+drop table fk_parent;
+-- run
+
+-- ============================================================
+-- 10. Composite ADD FOREIGN KEY over existing rows — exercises the shared
+-- existing-row validator's `not exists` orphan test across MORE THAN ONE
+-- referenced column (the multi-column match chain in the correlated subquery;
+-- single-column cases above only argue the composite path in comments).
+-- ============================================================
+create table fk_cparent (a integer, b integer, primary key (a, b));
+insert into fk_cparent values (1, 10), (2, 20);
+
+-- 10a. Composite SATISFIED — every existing (ref_a, ref_b) pair has a parent row.
+create table fk_cchild (id integer primary key, ref_a integer, ref_b integer);
+insert into fk_cchild values (1, 1, 10), (2, 2, 20);
+-- run
+
+alter table fk_cchild add constraint fk_ab foreign key (ref_a, ref_b) references fk_cparent(a, b);
+-- run
+
+-- installed and enforced going forward; a matching prefix on only ONE column is still an orphan
+insert into fk_cchild values (3, 1, 20);
+-- error:
+
+insert into fk_cchild values (4, 2, 20);
+select count(*) as c from fk_cchild;
+→ [{"c":3}]
+
+drop table fk_cchild;
+-- run
+
+-- 10b. Composite ORPHAN — (2, 99) matches the parent on `a` only ⇒ no full
+-- match ⇒ the add is rejected (the first-parent-col null test must not be
+-- fooled by the partial `a` match).
+create table fk_cchild (id integer primary key, ref_a integer, ref_b integer);
+insert into fk_cchild values (1, 1, 10), (2, 2, 99);
+-- run
+
+alter table fk_cchild add constraint fk_ab foreign key (ref_a, ref_b) references fk_cparent(a, b);
+-- error:
+
+-- not installed, not enforced
+select count(*) as c from foreign_key_info('fk_cchild') where name = 'fk_ab';
+→ [{"c":0}]
+
+drop table fk_cchild;
+drop table fk_cparent;
+-- run

package/test/logic/41.8-alter-savepoint-staged-rows.sqllogic

@@ -0,0 +1,443 @@
+-- ALTER TABLE column-shape changes (ADD / DROP / RENAME COLUMN) inside a transaction
+-- must not disturb the savepoint ledger of rows the transaction has already staged:
+-- rows staged BEFORE a savepoint survive `rollback to savepoint`, rows staged AFTER it
+-- are discarded. (DDL itself is not transactional — the rollback keeps the column
+-- change and only unwinds row writes.)
+--
+-- Cross-backend on purpose: under the memory module the pending rows live in its own
+-- transaction layers; under --store they live in the isolation wrapper's per-connection
+-- overlay, which every ALTER used to REBUILD (copy staged rows into a fresh staging
+-- table). The copy's first write lazily registered a fresh connection whose replayed
+-- savepoint stack sat ABOVE the copied rows, so the next `rollback to savepoint`
+-- discarded rows staged long before the savepoint (isolation-alter-forward-column-shape).
+
+-- ADD COLUMN: pre-savepoint row survives (backfilled), post-savepoint rows discarded.
+create table t1 (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into t1 values (1, 'a');
+-- run
+savepoint s;
+-- run
+insert into t1 values (2, 'b');
+-- run
+alter table t1 add column w text default 'z';
+-- run
+insert into t1 values (3, 'c', 'x');
+-- run
+rollback to savepoint s;
+-- run
+
+select id, v, w from t1 order by id;
+→ [{"id":1,"v":"a","w":"z"}]
+
+commit;
+-- run
+
+select id, v, w from t1 order by id;
+→ [{"id":1,"v":"a","w":"z"}]
+
+drop table t1;
+-- run
+
+-- DROP COLUMN (middle) with a committed row present: staged values realign under the
+-- narrower layout, and the savepoint ledger still splits pre/post rows correctly.
+create table t2 (id integer primary key, v text, x integer);
+-- run
+insert into t2 values (0, 'base', 100);
+-- run
+
+begin;
+-- run
+insert into t2 values (1, 'a', 10);
+-- run
+savepoint s;
+-- run
+insert into t2 values (2, 'b', 20);
+-- run
+alter table t2 drop column v;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, x from t2 order by id;
+→ [{"id":0,"x":100},{"id":1,"x":10}]
+
+drop table t2;
+-- run
+
+-- RENAME COLUMN: the rename does not change the column set, but the open layers still
+-- have to ADOPT the renamed schema — an eager savepoint snapshot left holding its frozen
+-- pre-rename schema fails `commitTransaction`'s snapshot-wrap identity check and the
+-- transaction's staged rows are dropped at COMMIT.
+create table t3 (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into t3 values (1, 'a');
+-- run
+savepoint s;
+-- run
+insert into t3 values (2, 'b');
+-- run
+alter table t3 rename column v to vv;
+-- run
+insert into t3 values (3, 'c');
+-- run
+rollback to savepoint s;
+-- run
+
+select id, vv from t3 order by id;
+→ [{"id":1,"vv":"a"}]
+
+commit;
+-- run
+
+select id, vv from t3 order by id;
+→ [{"id":1,"vv":"a"}]
+
+drop table t3;
+-- run
+
+-- ...and the same rename with no rollback: every staged row survives COMMIT.
+create table t3b (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into t3b values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table t3b rename column v to vv;
+-- run
+commit;
+-- run
+
+select id, vv from t3b order by id;
+→ [{"id":1,"vv":"a"}]
+
+drop table t3b;
+-- run
+
+-- A staged tombstone (an in-transaction DELETE of a committed row) survives the ALTER
+-- under a savepoint and still applies at COMMIT.
+create table t4 (id integer primary key, v text);
+-- run
+insert into t4 values (1, 'a'), (2, 'b');
+-- run
+
+begin;
+-- run
+delete from t4 where id = 1;
+-- run
+savepoint s;
+-- run
+alter table t4 add column w text default 'z';
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v, w from t4 order by id;
+→ [{"id":2,"v":"b","w":"z"}]
+
+drop table t4;
+-- run
+
+-- ALTER COLUMN SET NOT NULL that needs NO backfill: metadata-only, so it moves nothing an
+-- open layer derives — but the layers still have to ADOPT the new schema OBJECT, or the
+-- savepoint snapshot a `rollback to savepoint` swaps in keeps its frozen pre-ALTER schema,
+-- fails `commitTransaction`'s snapshot-wrap identity check, and the staged rows are dropped
+-- at COMMIT.
+create table t5 (id integer primary key, v text null);
+-- run
+
+begin;
+-- run
+insert into t5 values (1, 'a');
+-- run
+savepoint s;
+-- run
+insert into t5 values (2, 'b');
+-- run
+alter table t5 alter column v set not null;
+-- run
+insert into t5 values (3, 'c');
+-- run
+rollback to savepoint s;
+-- run
+
+select id, v from t5 order by id;
+→ [{"id":1,"v":"a"}]
+
+commit;
+-- run
+
+select id, v from t5 order by id;
+→ [{"id":1,"v":"a"}]
+
+drop table t5;
+-- run
+
+-- ALTER COLUMN SET NOT NULL, the DEFAULT-backfill flavor: a staged NULL is filled at the ALTER, and the
+-- filled row (staged before the later savepoint) survives that savepoint's rollback.
+create table t5b (id integer primary key, v text null default 'filled');
+-- run
+
+begin;
+-- run
+insert into t5b values (1, null);
+-- run
+alter table t5b alter column v set not null;
+-- run
+savepoint s;
+-- run
+insert into t5b values (2, 'b');
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from t5b order by id;
+→ [{"id":1,"v":"filled"}]
+
+drop table t5b;
+-- run
+
+-- ALTER COLUMN SET DATA TYPE: the pre-savepoint staged row survives the rollback with
+-- its value CONVERTED; the post-savepoint row is discarded.
+create table t6 (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into t6 values (1, '10');
+-- run
+savepoint s;
+-- run
+insert into t6 values (2, '20');
+-- run
+alter table t6 alter column v set data type integer;
+-- run
+insert into t6 values (3, 30);
+-- run
+rollback to savepoint s;
+-- run
+
+select id, v from t6 order by id;
+→ [{"id":1,"v":10}]
+
+commit;
+-- run
+
+select id, v from t6 order by id;
+→ [{"id":1,"v":10}]
+
+drop table t6;
+-- run
+
+-- ALTER COLUMN SET DEFAULT: metadata-only, but the staged rows and the savepoint
+-- ledger must still come through, and the new DEFAULT applies after the rollback.
+create table t7 (id integer primary key, v integer null);
+-- run
+
+begin;
+-- run
+insert into t7 values (1, 5);
+-- run
+savepoint s;
+-- run
+insert into t7 values (2, 6);
+-- run
+alter table t7 alter column v set default 99;
+-- run
+rollback to savepoint s;
+-- run
+insert into t7 (id) values (3);
+-- run
+commit;
+-- run
+
+select id, v from t7 order by id;
+→ [{"id":1,"v":5},{"id":3,"v":99}]
+
+drop table t7;
+-- run
+
+-- ADD CONSTRAINT UNIQUE: pre-savepoint staged row survives, post-savepoint rows are
+-- discarded, and the constraint (DDL) survives the rollback and enforces after COMMIT.
+create table t8 (id integer primary key, v text);
+-- run
+
+begin;
+-- run
+insert into t8 values (1, 'a');
+-- run
+savepoint s;
+-- run
+insert into t8 values (2, 'b');
+-- run
+alter table t8 add constraint u_v unique (v);
+-- run
+insert into t8 values (3, 'c');
+-- run
+rollback to savepoint s;
+-- run
+
+select id, v from t8 order by id;
+→ [{"id":1,"v":"a"}]
+
+commit;
+-- run
+
+select id, v from t8 order by id;
+→ [{"id":1,"v":"a"}]
+
+insert into t8 values (4, 'a');
+-- error: UNIQUE
+
+drop table t8;
+-- run
+
+-- DROP CONSTRAINT: the drop survives the rollback (DDL is not transactional), the
+-- pre-savepoint staged row survives, and a once-duplicate insert is accepted after COMMIT.
+create table t9 (id integer primary key, v text, constraint u_v unique (v));
+-- run
+insert into t9 values (0, 'dup');
+-- run
+
+begin;
+-- run
+insert into t9 values (1, 'a');
+-- run
+savepoint s;
+-- run
+alter table t9 drop constraint u_v;
+-- run
+insert into t9 values (2, 'dup');
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from t9 order by id;
+→ [{"id":0,"v":"dup"},{"id":1,"v":"a"}]
+
+insert into t9 values (3, 'dup');
+-- run
+
+select count(*) as c from t9 where v = 'dup';
+→ [{"c":2}]
+
+drop table t9;
+-- run
+
+-- RENAME CONSTRAINT: schema-only, but the renamed UNIQUE's implicit covering index moves
+-- under a new key in every open layer's index map, and the layers must re-freeze the new
+-- schema so a savepoint snapshot restored across the rename still commits its staged rows.
+create table t10s (id integer primary key, v text, constraint u_old unique (v));
+-- run
+
+begin;
+-- run
+insert into t10s values (1, 'a');
+-- run
+savepoint s;
+-- run
+insert into t10s values (2, 'b');
+-- run
+alter table t10s rename constraint u_old to u_new;
+-- run
+rollback to savepoint s;
+-- run
+commit;
+-- run
+
+select id, v from t10s order by id;
+→ [{"id":1,"v":"a"}]
+
+insert into t10s values (3, 'a');
+-- error: UNIQUE
+
+drop table t10s;
+-- run
+
+-- ...and the same rename with no savepoint across it:
+create table t10 (id integer primary key, v text, constraint u_old unique (v));
+-- run
+
+begin;
+-- run
+insert into t10 values (1, 'a');
+-- run
+alter table t10 rename constraint u_old to u_new;
+-- run
+commit;
+-- run
+
+select id, v from t10 order by id;
+→ [{"id":1,"v":"a"}]
+
+insert into t10 values (3, 'a');
+-- error: UNIQUE
+
+drop table t10;
+-- run
+
+-- ADD CONSTRAINT UNIQUE over a primary-key member with two in-transaction deletions:
+-- the two deletion markers share a = 1, and a naive uniqueness check over them would
+-- report a phantom duplicate. Deleted rows are not rows — the ALTER must succeed.
+create table t11 (a integer, b integer, primary key (a, b));
+-- run
+insert into t11 values (1, 1), (1, 2), (2, 1);
+-- run
+
+begin;
+-- run
+delete from t11 where a = 1;
+-- run
+alter table t11 add constraint u_a unique (a);
+-- run
+commit;
+-- run
+
+select a, b from t11 order by a, b;
+→ [{"a":2,"b":1}]
+
+insert into t11 values (3, 1);
+-- run
+insert into t11 values (3, 2);
+-- error: UNIQUE
+
+drop table t11;
+-- run
+
+-- A backfilling SET NOT NULL must not disturb an in-transaction deletion: the deleted
+-- row stays deleted (never resurrected carrying the DEFAULT) and the survivor is intact.
+create table t12 (id integer primary key, v text null default 'filled');
+-- run
+insert into t12 values (1, null), (2, 'b');
+-- run
+
+begin;
+-- run
+delete from t12 where id = 1;
+-- run
+alter table t12 alter column v set not null;
+-- run
+commit;
+-- run
+
+select id, v from t12 order by id;
+→ [{"id":2,"v":"b"}]
+
+drop table t12;