@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.10-alter-drop-column-foreign-key.sqllogic

@@ -0,0 +1,274 @@
+-- ALTER TABLE DROP COLUMN vs. the table's OWN foreign keys.
+--
+-- A foreign key records which of its own table's columns it constrains by POSITION
+-- (`foreignKeys[].columns` is an array of indices into that table's column list), so a
+-- DROP COLUMN has to renumber them — exactly as it already renumbers the primary key,
+-- the secondary indexes and the UNIQUE constraints. A key that loses any of its child
+-- columns is removed outright rather than narrowed (a key missing a child column is a
+-- different constraint against the parent's key). Left unshifted, a surviving key's
+-- index either dangles past the end of the column array (raw TypeError on the next
+-- enforced write) or silently slides onto an unrelated column.
+--
+-- These cases run under both the memory module (`yarn test`) and the store module
+-- (`yarn test:store`, which additionally round-trips the corrected keys through the
+-- persisted DDL). Assertions read `foreign_key_info`, which is module-agnostic and
+-- resolves the `from` column as `columns[fk.columns[seq]].name` — the very read that
+-- raises on a dangling index.
+--
+-- NOTE: the `-- error:` lines match the auto-generated constraint name (`_fk_<table>_<cols>`)
+-- on purpose — the name proves WHICH column is being enforced, which a generic `foreign key`
+-- match would not. If that naming convention ever changes, update these expectations; the
+-- convention itself is pinned by `41.4-alter-add-column-constraints.sqllogic` § 7e.
+--
+-- Most keys here are declared with `create table`; § 10 covers the same rule for a key
+-- an `alter table add column … references …` created, which is also the shape the engine
+-- reverts by dropping the just-added column.
+
+pragma foreign_keys = true;
+
+create table FkP (pid integer primary key);
+insert into FkP values (1), (2);
+
+-- ===================================================================
+-- 1. A key whose child column sits AFTER the dropped one shifts down and
+--    keeps constraining the same column.
+-- ===================================================================
+
+create table FkShift (id integer primary key, a integer, fkcol integer references FkP(pid));
+insert into FkShift values (1, 10, 1);
+
+-- Drop `a`, which precedes the FK child column: the recorded position 2 must become 1.
+alter table FkShift drop column a;
+
+-- Introspection resolves the child column (a dangling index throws here instead).
+select "from", "to" from foreign_key_info('FkShift');
+→ [{"from":"fkcol","to":"pid"}]
+
+-- Still enforced, and against the CORRECT column: an orphan is rejected. The
+-- constraint named in the error is the one declared on `fkcol`, not a slid-over key.
+insert into FkShift values (2, 99);
+-- error: _fk_fkshift_fkcol
+
+-- ...while a value present in the parent is accepted.
+insert into FkShift values (3, 2);
+select count(*) as c from FkShift;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 2. Dropping the key's ONLY child column removes the whole key — it must not
+--    slide onto the next column along. This is the silent-corruption case: with
+--    the key left in place, position 1 now names the unrelated text column `z`,
+--    which the engine would then check against the parent's integer key.
+-- ===================================================================
+
+create table FkGone (id integer primary key, fkcol integer references FkP(pid), z text);
+insert into FkGone values (1, 1, 'a');
+alter table FkGone drop column fkcol;
+
+-- No key survives, so `foreignKeys` is back to empty.
+select count(*) as c from foreign_key_info('FkGone');
+→ [{"c":0}]
+
+-- `z` is unconstrained: a text value that is no parent key inserts cleanly.
+insert into FkGone values (11, 'r');
+select count(*) as c from FkGone;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 3. A MULTI-column key that loses one of its columns is removed in full —
+--    not narrowed to its surviving columns.
+-- ===================================================================
+
+create table FkP2 (a integer, b integer, primary key (a, b));
+insert into FkP2 values (1, 2);
+
+create table FkMulti (id integer primary key, x integer, y integer, foreign key (x, y) references FkP2(a, b));
+insert into FkMulti values (1, 1, 2);
+
+-- Enforced over the pair while both columns exist.
+insert into FkMulti values (2, 9, 9);
+-- error: _fk_fkmulti_x_y
+
+alter table FkMulti drop column y;
+select count(*) as c from foreign_key_info('FkMulti');
+→ [{"c":0}]
+
+-- `x` alone is no longer constrained against FkP2.a — a narrowed leftover key
+-- would have rejected this.
+insert into FkMulti values (3, 77);
+select count(*) as c from FkMulti;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 4. Control: dropping a column the key does NOT use leaves it enforcing.
+-- ===================================================================
+
+create table FkKeep (id integer primary key, fkcol integer references FkP(pid), z text);
+insert into FkKeep values (1, 1, 'a');
+
+-- `z` is the trailing column — no recorded position changes.
+alter table FkKeep drop column z;
+select "from", "to" from foreign_key_info('FkKeep');
+→ [{"from":"fkcol","to":"pid"}]
+
+insert into FkKeep values (2, 99);
+-- error: _fk_fkkeep_fkcol
+insert into FkKeep values (3, 2);
+select count(*) as c from FkKeep;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 5. Two keys, one dropped and one shifted in the same statement: the partition
+--    must remove `f1`'s key AND renumber `f2`'s from position 2 to 1.
+-- ===================================================================
+
+create table FkTwo (id integer primary key, f1 integer references FkP(pid), f2 integer references FkP(pid));
+insert into FkTwo values (1, 1, 2);
+alter table FkTwo drop column f1;
+
+select "from", "to" from foreign_key_info('FkTwo');
+→ [{"from":"f2","to":"pid"}]
+
+-- The survivor enforces over f2, not over the vacated slot — and the error names
+-- f2's own constraint, so the shift landed on the right column.
+insert into FkTwo values (2, 99);
+-- error: _fk_fktwo_f2
+insert into FkTwo values (3, 1);
+select count(*) as c from FkTwo;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 6. A referential ACTION still fires correctly after a preceding drop — the
+--    cascade path reads the same child column indices.
+-- ===================================================================
+
+create table FkCascP (pid integer primary key);
+insert into FkCascP values (1), (2);
+
+create table FkCasc (id integer primary key, a integer, fkcol integer references FkCascP(pid) on delete cascade);
+insert into FkCasc values (1, 10, 1);
+insert into FkCasc values (2, 20, 2);
+
+-- Drop the column preceding the FK child column, then trigger the cascade.
+alter table FkCasc drop column a;
+delete from FkCascP where pid = 1;
+
+-- Only the child of the deleted parent went away.
+select id, fkcol from FkCasc order by id;
+→ [{"id":2,"fkcol":2}]
+
+-- ===================================================================
+-- 7. Declaration shape is irrelevant to the shift: an explicitly NAMED key,
+--    a MULTI-column key whose columns all move, and an `on update` action all
+--    renumber the same way. (The partition never reads `name`, and the actions
+--    read the shifted child positions.)
+-- ===================================================================
+
+create table FkNamed (id integer primary key, a integer, fkcol integer, constraint fk_named foreign key (fkcol) references FkP(pid));
+insert into FkNamed values (1, 10, 1);
+alter table FkNamed drop column a;
+select "from", "to", name from foreign_key_info('FkNamed');
+→ [{"from":"fkcol","to":"pid","name":"fk_named"}]
+insert into FkNamed values (2, 99);
+-- error: fk_named
+
+-- Both child positions of a composite key move down one.
+create table FkMultiShift (id integer primary key, dead integer, x integer, y integer, foreign key (x, y) references FkP2(a, b));
+insert into FkMultiShift values (1, 0, 1, 2);
+alter table FkMultiShift drop column dead;
+select "from", "to", seq from foreign_key_info('FkMultiShift') order by seq;
+→ [{"from":"x","to":"a","seq":0},{"from":"y","to":"b","seq":1}]
+insert into FkMultiShift values (2, 9, 9);
+-- error: _fk_fkmultishift_x_y
+insert into FkMultiShift values (3, 1, 2);
+select count(*) as c from FkMultiShift;
+→ [{"c":2}]
+
+-- `on update cascade` rewrites the child through the shifted position.
+create table FkUpP (pid integer primary key);
+insert into FkUpP values (1);
+create table FkUpC (id integer primary key, dead integer, fkcol integer references FkUpP(pid) on update cascade);
+insert into FkUpC values (1, 0, 1);
+alter table FkUpC drop column dead;
+update FkUpP set pid = 5 where pid = 1;
+select id, fkcol from FkUpC;
+→ [{"id":1,"fkcol":5}]
+
+-- ===================================================================
+-- 8. A DEFERRED key still resolves at COMMIT against the shifted position.
+-- ===================================================================
+
+create table FkDef (id integer primary key, dead integer, fkcol integer references FkP(pid) deferrable initially deferred);
+alter table FkDef drop column dead;
+begin;
+insert into FkDef values (1, 7);
+insert into FkP values (7);
+commit;
+select id, fkcol from FkDef;
+→ [{"id":1,"fkcol":7}]
+
+-- ===================================================================
+-- 9. A SELF-referential key shifts on the child side and keeps resolving its
+--    parent column by name against the narrowed table.
+-- ===================================================================
+
+create table FkSelf (id integer primary key, a integer, parent_id integer null references FkSelf(id));
+insert into FkSelf values (1, 10, null);
+alter table FkSelf drop column a;
+select "from", "to" from foreign_key_info('FkSelf');
+→ [{"from":"parent_id","to":"id"}]
+insert into FkSelf values (2, 1);
+insert into FkSelf values (3, 77);
+-- error: _fk_fkself_parent_id
+select count(*) as c from FkSelf;
+→ [{"c":2}]
+
+-- ===================================================================
+-- 10. A key created by `add column … references …` is removed by dropping that
+--     same column — the shape the engine's own ADD COLUMN revert path takes.
+-- ===================================================================
+
+create table FkAdded (id integer primary key, z text);
+insert into FkAdded values (1, 'a');
+alter table FkAdded add column fkcol integer null references FkP(pid);
+select count(*) as c from foreign_key_info('FkAdded');
+→ [{"c":1}]
+alter table FkAdded drop column fkcol;
+select count(*) as c from foreign_key_info('FkAdded');
+→ [{"c":0}]
+
+-- ===================================================================
+-- 11. DROP COLUMN lands *between* a deferred check being queued and the COMMIT
+--     that evaluates it. The parked check carries a row image and a plan frozen
+--     at write time, so a column vanishing under it on either side is the shape
+--     most likely to mismatch arity. Case 8 above drops before the transaction;
+--     these drop inside it.
+-- ===================================================================
+
+-- parent side
+create table FkMidP (pid integer primary key, extra text);
+create table FkMidC (id integer primary key,
+	fkcol integer null references FkMidP(pid) deferrable initially deferred);
+
+begin;
+insert into FkMidC values (10, 1);
+insert into FkMidP values (1, 'x');
+alter table FkMidP drop column extra;
+commit;
+
+select id, fkcol from FkMidC;
+→ [{"id":10,"fkcol":1}]
+
+-- child side (the table the parked row itself belongs to)
+create table FkMid2P (pid integer primary key);
+create table FkMid2C (id integer primary key, extra text,
+	fkcol integer null references FkMid2P(pid) deferrable initially deferred);
+
+begin;
+insert into FkMid2C values (10, 'x', 1);
+insert into FkMid2P values (1);
+alter table FkMid2C drop column extra;
+commit;
+
+select id, fkcol from FkMid2C;
+→ [{"id":10,"fkcol":1}]

package/test/logic/41.10.1-alter-drop-column-unique-index.sqllogic

@@ -0,0 +1,169 @@
+-- 41.10.1-alter-drop-column-unique-index.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Subject: `ALTER TABLE … DROP COLUMN` over a standalone `CREATE INDEX` that spans the
+-- dropped column — which of the two fates the index meets, and whether the rows it
+-- indexes are still answered correctly afterwards.
+--
+-- A UNIQUE index spanning the dropped column must be removed OUTRIGHT, not narrowed to
+-- its surviving columns — narrowing invents a UNIQUE the table never declared, and one
+-- nothing enforces (the matching derived UNIQUE constraint is removed, since a
+-- constraint missing one of its columns is a different, stronger constraint). A
+-- narrowed survivor would then be reported by index_info, trusted by the planner's
+-- at-most-one-matching-row proofs, and re-persisted as a real CREATE UNIQUE INDEX.
+-- A plain (non-unique) index is narrowed instead, and survives.
+--
+-- Sections 4 and 5 index rows written BEFORE the drop, which is what exercises a
+-- module's obligation to reshape the index's PHYSICAL structure — re-encode the one the
+-- drop narrowed (its key holds one fewer column value), tear down the one it removed. A
+-- module that only rewrites the schema answers a later indexed lookup SHORT (the narrowed
+-- case) or DOUBLE (a same-named index rebuilt over a store still holding the removed
+-- index's entries).
+--
+-- Every case runs under the memory module (`yarn test`) and the store module
+-- (`yarn test:store`); the assertions read module-agnostic engine introspection.
+
+-- ===================================================================
+-- 1. A UNIQUE index spanning the dropped column is removed outright
+-- ===================================================================
+
+create table DcUx (id integer primary key, b integer, c integer);
+create unique index ux_bc on DcUx (b, c);
+alter table DcUx drop column b;
+-- run
+
+-- Neither the index nor its derived constraint survives.
+select count(*) as c from index_info('DcUx');
+→ [{"c":0}]
+select count(*) as c from unique_constraint_info('DcUx');
+→ [{"c":0}]
+
+-- And nothing is enforced over the surviving column: duplicate c values are accepted,
+-- which is correct — no UNIQUE over (c) was ever declared.
+insert into DcUx values (1, 5);
+insert into DcUx values (2, 5);
+select count(*) as c from DcUx;
+→ [{"c":2}]
+
+drop table DcUx;
+-- run
+
+-- ===================================================================
+-- 2. A UNIQUE index that keeps every column is renumbered, not dropped
+-- ===================================================================
+
+create table DcKeep (id integer primary key, b integer, c integer, d integer);
+create unique index ux_cd on DcKeep (c, d);
+insert into DcKeep values (1, 9, 10, 11);
+alter table DcKeep drop column b;
+-- run
+
+-- Survives over its own (renumbered) columns, still unique.
+select index_name, column_name from index_info('DcKeep') order by column_name;
+→ [{"index_name":"ux_cd","column_name":"c"},{"index_name":"ux_cd","column_name":"d"}]
+
+insert into DcKeep values (2, 10, 11);
+-- error: UNIQUE
+
+insert into DcKeep values (3, 10, 12);
+select count(*) as c from DcKeep;
+→ [{"c":2}]
+
+drop table DcKeep;
+-- run
+
+-- ===================================================================
+-- 3. A plain (non-unique) index spanning the dropped column is narrowed —
+--    it constrains nothing, so the surviving columns remain a usable index
+-- ===================================================================
+
+create table DcPlain (id integer primary key, b integer, c integer);
+create index ix_bc on DcPlain (b, c);
+alter table DcPlain drop column b;
+-- run
+
+select index_name, column_name from index_info('DcPlain');
+→ [{"index_name":"ix_bc","column_name":"c"}]
+
+-- Duplicates are fine on a plain index, and the index still serves lookups.
+insert into DcPlain values (1, 5);
+insert into DcPlain values (2, 5);
+select count(*) as c from DcPlain where c = 5;
+→ [{"c":2}]
+
+drop table DcPlain;
+-- run
+
+-- ===================================================================
+-- 4. A narrowed index still answers lookups over rows indexed BEFORE the drop
+-- ===================================================================
+--
+-- The pre-drop rows are the point: their index entries were written under the WIDE key
+-- (b's value ahead of c's) while every later seek computes the NARROW one. A module that
+-- leaves them unreshaped answers the seek short — `c = 100` finds nothing — and a later
+-- DELETE cannot match its own entries, so they orphan.
+
+create table DcPre (id integer primary key, b integer, c integer);
+create index ix_bc on DcPre (b, c);
+insert into DcPre values (1, 10, 100);
+insert into DcPre values (2, 20, 200);
+alter table DcPre drop column b;
+-- run
+
+select index_name, column_name from index_info('DcPre');
+→ [{"index_name":"ix_bc","column_name":"c"}]
+
+-- Each pre-drop row is reachable through the narrowed index, exactly once.
+select id from DcPre where c = 100;
+→ [{"id":1}]
+select id from DcPre where c > 0 order by id;
+→ [{"id":1},{"id":2}]
+
+-- A row inserted after the drop joins them under the same encoding.
+insert into DcPre values (3, 300);
+select id from DcPre where c > 150 order by id;
+→ [{"id":2},{"id":3}]
+
+-- DELETE recomputes each index key: a table drained through the index leaves no row
+-- findable, pre-drop or post-drop.
+delete from DcPre;
+select count(*) as n from DcPre;
+→ [{"n":0}]
+select count(*) as n from DcPre where c > 0;
+→ [{"n":0}]
+
+drop table DcPre;
+-- run
+
+-- ===================================================================
+-- 5. Re-creating an index under the REMOVED index's name gets a clean structure
+-- ===================================================================
+--
+-- The single-column index collapses (its only column is gone), so its name is free again.
+-- A module that left the removed index's physical structure behind hands it to the new
+-- index of the same name, which then holds both encodings — a range scan yields each row
+-- twice, and a count is doubled.
+
+create table DcReuse (id integer primary key, b integer, c integer);
+create index ix_b on DcReuse (b);
+insert into DcReuse values (1, 10, 100);
+insert into DcReuse values (2, 20, 200);
+alter table DcReuse drop column b;
+-- run
+
+select count(*) as n from index_info('DcReuse');
+→ [{"n":0}]
+
+create index ix_b on DcReuse (c);
+-- run
+
+select id from DcReuse where c > 0 order by id;
+→ [{"id":1},{"id":2}]
+select count(*) as n from DcReuse where c > 0;
+→ [{"n":2}]
+select id from DcReuse where c = 100;
+→ [{"id":1}]
+
+drop table DcReuse;
+-- run