@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.2.3-alter-column-set-not-null-pk-backfill.sqllogic

@@ -0,0 +1,310 @@
+-- ALTER COLUMN ... SET NOT NULL on a PRIMARY KEY member: the null → DEFAULT backfill moves the
+-- key VALUES, so two rows that differed only by NULL-vs-DEFAULT there would merge. Key membership
+-- does not imply NOT NULL (docs/schema.md § "Primary-key nullability"), so any key column can be
+-- nullable and hold NULLs — the cases below reach that state via the all-columns key a table with
+-- no declared PRIMARY KEY gets, and 43.3-nullable-primary-key § 10 reaches it via a declared key.
+--
+-- Cross-module: both backends treat the backfill as a primary-key re-key and ask the same two
+-- questions before mutating anything (memory: MemoryTableManager.validateRekeyedPrimaryKey over
+-- the CONVERTED rows; store: StoreTable.validateRekeyedPrimaryKey with the same per-row mapper) —
+-- a collision the transaction can SEE is CONSTRAINT, a collision confined to rows only a rollback
+-- could restore is BUSY, and either refusal leaves the table and the transaction untouched. An
+-- accepted backfill physically re-keys: memory re-derives each open layer's staged deletion keys
+-- (TransactionLayer.convertColumn), the store re-encodes the data keys after the value rewrite
+-- (StoreModuleAlterColumn.alterColumnChange → rekeyRows), and the isolation overlay the store runs
+-- behind re-keys its staged deletion markers (alter-migration.ts derivePkRekey / backfillStagedNotNull).
+
+-- ===================================
+-- 1. Two COMMITTED rows that converge under the backfill: refused (CONSTRAINT), nothing changes.
+-- ===================================
+
+create table t_bf1 (x integer null default 0, y integer null);
+insert into t_bf1 (x, y) values (null, 1), (0, 1);
+-- run
+
+alter table t_bf1 alter column x set not null;
+-- error: collides under the new key definition
+
+select count(*) as n from t_bf1;
+→ [{"n":2}]
+
+select count(*) as n from t_bf1 where x is null;
+→ [{"n":1}]
+
+select name, "notnull" from table_info('t_bf1') where name = 'x';
+→ [{"name":"x","notnull":0}]
+
+drop table t_bf1;
+
+-- ===================================
+-- 2. A STAGED insert converging with a committed row is a duplicate this transaction's own
+--    select would return: refused (CONSTRAINT), transaction still usable.
+-- ===================================
+
+create table t_bf2 (x integer null default 0, y integer null);
+insert into t_bf2 (x, y) values (null, 1);
+-- run
+
+begin;
+insert into t_bf2 (x, y) values (0, 1);
+-- run
+
+alter table t_bf2 alter column x set not null;
+-- error: collides under the new key definition
+
+select count(*) as n from t_bf2;
+→ [{"n":2}]
+
+rollback;
+select x, y from t_bf2;
+→ [{"x":null,"y":1}]
+
+drop table t_bf2;
+
+-- ===================================
+-- 3. A collision confined to a committed row this transaction has DELETED: invisible to the
+--    transaction's view, but it must survive a rollback and the rebuilt key structure cannot
+--    hold the pair — refused as retryable (BUSY), transaction usable, retry after commit lands.
+-- ===================================
+
+create table t_bf3 (x integer null default 0, y integer null);
+insert into t_bf3 (x, y) values (null, 1), (0, 1), (null, 2);
+-- run
+
+begin;
+delete from t_bf3 where x is null and y = 1;
+-- run
+
+alter table t_bf3 alter column x set not null;
+-- error: still collide under the new key definition
+
+select count(*) as n from t_bf3;
+→ [{"n":2}]
+
+commit;
+alter table t_bf3 alter column x set not null;
+select x, y from t_bf3 order by y;
+→ [{"x":0,"y":1},{"x":0,"y":2}]
+
+drop table t_bf3;
+
+-- ===================================
+-- 4. A staged delete that REMOVES the collision (delete the NULL row, re-insert its backfilled
+--    twin) is accepted, and exactly one row per key survives the commit.
+-- ===================================
+
+create table t_bf4 (x integer null default 0, y integer null);
+insert into t_bf4 (x, y) values (null, 1), (null, 2);
+-- run
+
+begin;
+delete from t_bf4 where x is null and y = 1;
+insert into t_bf4 (x, y) values (0, 1);
+alter table t_bf4 alter column x set not null;
+select x, y from t_bf4 order by y;
+→ [{"x":0,"y":1},{"x":0,"y":2}]
+
+commit;
+select x, y from t_bf4 order by y;
+→ [{"x":0,"y":1},{"x":0,"y":2}]
+
+select count(*) as n from t_bf4 where x = 0 and y = 1;
+→ [{"n":1}]
+
+drop table t_bf4;
+
+-- ===================================
+-- 5. RESURRECTION guard: a row DELETED in this transaction whose key the backfill moves must
+--    stay deleted — through the ALTER and through the commit. (The staged deletion was recorded
+--    under the pre-backfill key; a replay under that key would land nowhere and the row would
+--    reappear with the backfilled value.)
+-- ===================================
+
+create table t_bf5 (x integer null default 0, y integer null);
+insert into t_bf5 (x, y) values (null, 1), (null, 2);
+-- run
+
+begin;
+delete from t_bf5 where x is null and y = 1;
+select count(*) as n from t_bf5;
+→ [{"n":1}]
+
+alter table t_bf5 alter column x set not null;
+select x, y from t_bf5;
+→ [{"x":0,"y":2}]
+
+commit;
+select x, y from t_bf5;
+→ [{"x":0,"y":2}]
+
+drop table t_bf5;
+
+-- ===================================
+-- 6. A NON-colliding key-column backfill is accepted, and the backfilled row is still FINDABLE
+--    by an equality lookup on its new key and DELETABLE — i.e. the key bytes followed the value
+--    (the store used to rewrite the row payload under its old NULL-encoding key).
+-- ===================================
+
+create table t_bf6 (x integer null default 7, y integer null);
+insert into t_bf6 (x, y) values (null, 1), (3, 1);
+alter table t_bf6 alter column x set not null;
+select x, y from t_bf6 order by x;
+→ [{"x":3,"y":1},{"x":7,"y":1}]
+
+select x, y from t_bf6 where x = 7 and y = 1;
+→ [{"x":7,"y":1}]
+
+insert into t_bf6 (x, y) values (7, 1);
+-- error: UNIQUE constraint failed
+
+delete from t_bf6 where x = 7 and y = 1;
+select x, y from t_bf6;
+→ [{"x":3,"y":1}]
+
+insert into t_bf6 (x, y) values (7, 1);
+select count(*) as n from t_bf6 where x = 7;
+→ [{"n":1}]
+
+drop table t_bf6;
+
+-- ===================================
+-- 7. Single-column key (the whole row IS the key): the scalar key form re-keys too.
+-- ===================================
+
+create table t_bf7 (x integer null default 5);
+insert into t_bf7 (x) values (null), (3);
+alter table t_bf7 alter column x set not null;
+select x from t_bf7 order by x;
+→ [{"x":3},{"x":5}]
+
+select x from t_bf7 where x = 5;
+→ [{"x":5}]
+
+delete from t_bf7 where x = 5;
+select x from t_bf7;
+→ [{"x":3}]
+
+drop table t_bf7;
+
+-- ===================================
+-- 8. Two STAGED rows converging under the backfill: refused (CONSTRAINT), rollback clean.
+--    (Behind the isolation layer this is the overlay's own pre-flight; on plain memory it is
+--    the manager's effective-row probe — same message.)
+-- ===================================
+
+create table t_bf9 (x integer null default 0, y integer null);
+-- run
+
+begin;
+insert into t_bf9 (x, y) values (null, 1), (0, 1);
+-- run
+
+alter table t_bf9 alter column x set not null;
+-- error: collides under the new key definition
+
+rollback;
+select count(*) as n from t_bf9;
+→ [{"n":0}]
+
+drop table t_bf9;
+
+-- ===================================
+-- 9. A staged NULL row that backfills onto the key of a committed row this transaction has
+--     DELETED: the deletion is that row's before-image, not a duplicate — accepted, and the
+--     staged row is what survives the commit.
+-- ===================================
+
+create table t_bf10 (x integer null default 0, y integer null);
+insert into t_bf10 (x, y) values (0, 1);
+-- run
+
+begin;
+delete from t_bf10 where x = 0 and y = 1;
+insert into t_bf10 (x, y) values (null, 1);
+alter table t_bf10 alter column x set not null;
+select x, y from t_bf10;
+→ [{"x":0,"y":1}]
+
+commit;
+select x, y from t_bf10;
+→ [{"x":0,"y":1}]
+
+select count(*) as n from t_bf10 where x = 0 and y = 1;
+→ [{"n":1}]
+
+drop table t_bf10;
+
+-- ===================================
+-- 10. A tightening the transaction can see NO NULL for is metadata-only: the committed keys do
+--     not move, and a staged deletion of a NULL-keyed committed row still lands at commit.
+-- ===================================
+
+create table t_bf11 (x integer null default 0, y integer null);
+insert into t_bf11 (x, y) values (null, 1), (2, 2);
+-- run
+
+begin;
+delete from t_bf11 where x is null and y = 1;
+alter table t_bf11 alter column x set not null;
+select x, y from t_bf11;
+→ [{"x":2,"y":2}]
+
+commit;
+select x, y from t_bf11;
+→ [{"x":2,"y":2}]
+
+insert into t_bf11 (x, y) values (null, 3);
+-- error: NOT NULL
+
+drop table t_bf11;
+
+-- ===================================
+-- 11. The same backfill on a NON-key column is unchanged: no re-key, values filled, key intact.
+-- ===================================
+
+create table t_bf12 (id integer primary key, v integer null default 9);
+insert into t_bf12 values (1, null), (2, null), (3, 4);
+begin;
+delete from t_bf12 where id = 2;
+alter table t_bf12 alter column v set not null;
+select id, v from t_bf12 order by id;
+→ [{"id":1,"v":9},{"id":3,"v":4}]
+
+commit;
+select id, v from t_bf12 order by id;
+→ [{"id":1,"v":9},{"id":3,"v":4}]
+
+select id, v from t_bf12 where id = 1;
+→ [{"id":1,"v":9}]
+
+drop table t_bf12;
+
+-- ===================================
+-- 12. A SECONDARY INDEX over an untouched column still resolves after the re-key: its entries
+--     embed the primary key, which the backfill just moved. Both the committed rebuild (base /
+--     store re-key) and the open-layer rebuild (TransactionLayer.convertColumn) are exercised.
+-- ===================================
+
+-- Table-level `unique` (not a standalone `create index`) so the file needs no
+-- `-- requires-capability: standalone-index-ddl` and runs on every backend. The same case
+-- built with a standalone `create index` lives in
+-- 41.2.3.1-alter-column-set-not-null-pk-backfill-secondary-index.sqllogic, which does declare it.
+create table t_bf13 (x integer null default 7, y integer null unique);
+insert into t_bf13 (x, y) values (3, 2);
+-- run
+
+begin;
+insert into t_bf13 (x, y) values (null, 1);
+alter table t_bf13 alter column x set not null;
+select x, y from t_bf13 where y = 1;
+→ [{"x":7,"y":1}]
+
+commit;
+select x, y from t_bf13 where y = 1;
+→ [{"x":7,"y":1}]
+
+delete from t_bf13 where y = 1;
+select x, y from t_bf13;
+→ [{"x":3,"y":2}]
+
+drop table t_bf13;

package/test/logic/41.2.3.1-alter-column-set-not-null-pk-backfill-secondary-index.sqllogic

@@ -0,0 +1,37 @@
+-- 41.2.3.1-alter-column-set-not-null-pk-backfill-secondary-index.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 41.2.3-alter-column-set-not-null-pk-backfill's former § 12: a standalone
+-- `create index` needs standalone index DDL, which not every backend implements, and the
+-- `-- requires-capability:` directive is whole-file — leaving this case in the parent file
+-- would have made its eleven other primary-key-backfill sections, which need no index DDL,
+-- skippable too. 41.2.3 § 12 now covers the same ground via a table-level `unique` column
+-- instead, so it needs no directive; this file keeps the standalone-index-DDL shape covered.
+--
+-- Subject: a SECONDARY INDEX (built via standalone `create index`, not `unique`) over an
+-- untouched column still resolves after ALTER COLUMN ... SET NOT NULL backfills and re-keys
+-- the primary key. Its entries embed the primary key, which the backfill just moved. Both
+-- the committed rebuild (base / store re-key) and the open-layer rebuild
+-- (TransactionLayer.convertColumn) are exercised.
+
+create table t_bf13 (x integer null default 7, y integer null);
+create index ix_bf13 on t_bf13 (y);
+insert into t_bf13 (x, y) values (3, 2);
+-- run
+
+begin;
+insert into t_bf13 (x, y) values (null, 1);
+alter table t_bf13 alter column x set not null;
+select x, y from t_bf13 where y = 1;
+→ [{"x":7,"y":1}]
+
+commit;
+select x, y from t_bf13 where y = 1;
+→ [{"x":7,"y":1}]
+
+delete from t_bf13 where y = 1;
+select x, y from t_bf13;
+→ [{"x":3,"y":2}]
+
+drop table t_bf13;

package/test/logic/41.3-alter-add-column-unique.sqllogic

@@ -0,0 +1,184 @@
+-- ALTER TABLE ADD COLUMN with an inline column-level UNIQUE.
+--
+-- An inline UNIQUE on the new column is routed through the module's `addConstraint`
+-- UNIQUE path — the same path `ALTER TABLE ADD CONSTRAINT … UNIQUE` uses — so it is
+-- materialized, enforced, and (store) persisted, symmetric with CREATE TABLE. These
+-- cases run under both the memory module (`yarn test`) and the store module
+-- (`yarn test:store`); assertions read engine-catalog introspection (table_info /
+-- unique_constraint_info / index_info), which is module-agnostic.
+
+-- ===================================================================
+-- 1. Basic: enforcement + introspection (unnamed inline UNIQUE)
+-- ===================================================================
+
+create table AddU (id integer primary key);
+alter table AddU add column u integer unique;
+
+-- The constraint is materialized and surfaces in introspection (unnamed → name null,
+-- one row per constrained column).
+select name, column_name from unique_constraint_info('AddU');
+→ [{"name":null,"column_name":"u"}]
+
+-- Forward enforcement: a duplicate value is rejected.
+insert into AddU values (1, 5);
+insert into AddU values (2, 5);
+-- error: UNIQUE constraint failed
+
+-- A distinct value still inserts.
+insert into AddU values (3, 6);
+select count(*) as c from AddU;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 2. A named inline UNIQUE round-trips its name
+-- ===================================================================
+
+create table AddNamed (id integer primary key);
+alter table AddNamed add column sku text constraint uq_sku unique;
+select name, column_name from unique_constraint_info('AddNamed');
+→ [{"name":"uq_sku","column_name":"sku"}]
+
+-- Enforcement is active under the named constraint.
+insert into AddNamed values (1, 'a');
+insert into AddNamed values (2, 'a');
+-- error: UNIQUE constraint failed
+
+-- ===================================================================
+-- 3. Existing NULLs are distinct: the add succeeds over multiple NULLs,
+--    and forward duplicates of a non-NULL value are still rejected.
+-- ===================================================================
+
+create table AddNull (id integer primary key);
+insert into AddNull values (1), (2);
+-- Existing rows backfill the new (nullable) column with NULL (no DEFAULT); NULLs are
+-- distinct, so the UNIQUE add succeeds over the two existing NULL rows.
+alter table AddNull add column code integer null unique;
+select count(*) as c from unique_constraint_info('AddNull');
+→ [{"c":1}]
+
+-- Two non-NULL duplicates collide going forward.
+insert into AddNull values (3, 7);
+insert into AddNull values (4, 7);
+-- error: UNIQUE constraint failed
+
+-- ===================================================================
+-- 4. Literal DEFAULT that duplicates across existing rows: the UNIQUE add
+--    fails and the column is fully reverted (no half-applied column /
+--    constraint / index, original schema intact).
+-- ===================================================================
+
+create table AddDefDup (id integer primary key);
+insert into AddDefDup values (1), (2);
+-- DEFAULT 5 backfills the same value to both existing rows → immediate duplicate.
+alter table AddDefDup add column u integer default 5 unique;
+-- error: UNIQUE constraint failed
+
+-- Revert: the column is gone, no orphan constraint, no orphan index.
+select count(*) as c from table_info('AddDefDup') where name = 'u';
+→ [{"c":0}]
+select count(*) as c from unique_constraint_info('AddDefDup');
+→ [{"c":0}]
+select count(*) as c from index_info('AddDefDup');
+→ [{"c":0}]
+
+-- Original schema is intact and usable (single id column).
+insert into AddDefDup values (3);
+select count(*) as c from AddDefDup;
+→ [{"c":3}]
+
+-- ===================================================================
+-- 5. Combined revert: ADD COLUMN carrying BOTH a UNIQUE and a CHECK, where the
+--    UNIQUE materializes successfully (single existing row → no duplicate) but the
+--    CHECK then fails over the backfilled row. The revert must tear down the unique
+--    covering structure too — no orphan in index_info / unique_constraint_info.
+-- ===================================================================
+
+create table AddCombo (id integer primary key);
+insert into AddCombo values (1);
+-- DEFAULT 0 over the single row: UNIQUE passes (one row), but CHECK (u > 0) fails.
+alter table AddCombo add column u integer default 0 check (u > 0) unique;
+-- error: CHECK constraint
+
+-- Full revert: column gone, and neither the unique constraint nor its covering index
+-- (memory) survives as an orphan.
+select count(*) as c from table_info('AddCombo') where name = 'u';
+→ [{"c":0}]
+select count(*) as c from unique_constraint_info('AddCombo');
+→ [{"c":0}]
+select count(*) as c from index_info('AddCombo');
+→ [{"c":0}]
+
+-- The table still works under its original shape, and re-adding the same column with
+-- a CHECK-satisfying DEFAULT now succeeds (proving no stale constraint/index lingers).
+alter table AddCombo add column u integer default 1 check (u > 0) unique;
+select count(*) as c from unique_constraint_info('AddCombo');
+→ [{"c":1}]
+select u from AddCombo;
+→ [{"u":1}]
+
+-- ===================================================================
+-- 6. Standalone DROP COLUMN of a single-column-UNIQUE column. The general
+--    dropColumn fix (prune the dangling UNIQUE + tear down its covering index)
+--    is what the ADD COLUMN revert path relies on; exercise it directly here.
+-- ===================================================================
+
+create table DropU (id integer primary key, a integer, b integer unique);
+insert into DropU values (1, 10, 100);
+-- b is enforced unique while it exists.
+insert into DropU values (2, 20, 100);
+-- error: UNIQUE constraint failed
+alter table DropU drop column b;
+-- Constraint and its covering index are both gone — no orphan.
+select count(*) as c from unique_constraint_info('DropU');
+→ [{"c":0}]
+select count(*) as c from index_info('DropU');
+→ [{"c":0}]
+-- The table is usable under its narrowed shape (b no longer enforced/present).
+insert into DropU values (3, 30);
+select count(*) as c from DropU;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 7. Standalone DROP COLUMN of a column that participates in a MULTI-column
+--    UNIQUE: the whole constraint is removed (a UNIQUE missing a column is a
+--    different constraint), AND its covering index is torn down — not left
+--    orphaned as a narrowed structure over the surviving columns.
+-- ===================================================================
+
+create table DropMultiIn (id integer primary key, a integer, b integer, constraint uq_ab unique (a, b));
+insert into DropMultiIn values (1, 1, 2);
+insert into DropMultiIn values (2, 1, 2);
+-- error: UNIQUE constraint failed
+alter table DropMultiIn drop column b;
+-- The entire uq_ab constraint is gone — and so is its covering index (no orphan
+-- narrowed to column a, which a prior narrow-not-remove bug would have left behind).
+select count(*) as c from unique_constraint_info('DropMultiIn');
+→ [{"c":0}]
+select count(*) as c from index_info('DropMultiIn');
+→ [{"c":0}]
+-- a alone is no longer constrained: a duplicate value is now allowed.
+insert into DropMultiIn values (3, 1);
+insert into DropMultiIn values (4, 1);
+select count(*) as c from DropMultiIn;
+→ [{"c":3}]
+
+-- ===================================================================
+-- 8. Standalone DROP COLUMN of a column NOT in a multi-column UNIQUE: the
+--    constraint survives with its column indices shifted over the removed slot
+--    and still enforces over the correct (renumbered) columns.
+-- ===================================================================
+
+create table DropMultiOut (id integer primary key, x integer, a integer, b integer, constraint uq_ab unique (a, b));
+insert into DropMultiOut values (1, 99, 1, 2);
+-- Drop x (lower index than a and b, not part of uq_ab): the constraint's column
+-- indices shift down by one but it survives intact.
+alter table DropMultiOut drop column x;
+select name, column_name from unique_constraint_info('DropMultiOut') order by column_name;
+→ [{"name":"uq_ab","column_name":"a"},{"name":"uq_ab","column_name":"b"}]
+-- Still enforces (a, b) after the shift: the same (a, b) pair collides…
+insert into DropMultiOut values (2, 1, 2);
+-- error: UNIQUE constraint failed
+-- …but a distinct pair is allowed.
+insert into DropMultiOut values (3, 5, 6);
+select count(*) as c from DropMultiOut;
+→ [{"c":2}]