@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.15-alter-column-default-type-check.sqllogic

@@ -0,0 +1,178 @@
+-- ALTER COLUMN SET DEFAULT / SET DATA TYPE are checked against the column's
+-- (current, or newly-set) declared type — the same `foldDefaultToType` guard
+-- CREATE TABLE runs (see 10.1.7-create-table-default-type-check.sqllogic), so an
+-- ALTER cannot mint a column CREATE TABLE would refuse.
+
+-- ============================================================
+-- 1. SET DEFAULT: the new literal default must convert to the column's CURRENT type
+-- ============================================================
+
+create table t_sd (id integer primary key, n integer null);
+insert into t_sd (id, n) values (1, 5);
+-- run
+
+alter table t_sd alter column n set default 'abc';
+-- error: Type conversion failed
+
+-- The column keeps its previous default (none here) — a later insert relying on
+-- it still sees no default applied, and the column's type is unchanged.
+insert into t_sd (id) values (2);
+select id, n from t_sd order by id;
+→ [{"id":1,"n":5},{"id":2,"n":null}]
+
+drop table t_sd;
+-- run
+
+-- A refused SET DEFAULT also leaves an EXISTING default in place — the column is
+-- not left defaultless by the failed statement.
+create table t_sd_keep (id integer primary key, n integer default 3);
+alter table t_sd_keep alter column n set default 'abc';
+-- error: Type conversion failed
+
+insert into t_sd_keep (id) values (1);
+select n from t_sd_keep where id = 1;
+→ [{"n":3}]
+
+drop table t_sd_keep;
+-- run
+
+-- A convertible literal SET DEFAULT still succeeds, and a later insert stores it
+-- already converted.
+create table t_sd_ok (id integer primary key, n integer);
+alter table t_sd_ok alter column n set default '7';
+-- run
+
+insert into t_sd_ok (id) values (1);
+select n, typeof(n) as t from t_sd_ok where id = 1;
+→ [{"n":7,"t":"integer"}]
+
+drop table t_sd_ok;
+-- run
+
+-- ============================================================
+-- 2. SET DATA TYPE: the column's EXISTING stored default must convert to the NEW type
+--
+-- Each row below supplies `n` explicitly (a value that DOES convert to the new
+-- type) so the retype's own value-conversion never fails — the only thing under
+-- test is whether the column's DECLARED (not necessarily used) default converts.
+-- ============================================================
+
+create table t_retype (id integer primary key, n text null default 'abc');
+insert into t_retype (id, n) values (1, '99');
+-- run
+
+alter table t_retype alter column n set data type integer;
+-- error: Type conversion failed
+
+-- Neither the type nor the stored rows moved.
+select id, n, typeof(n) as t from t_retype order by id;
+→ [{"id":1,"n":"99","t":"text"}]
+
+drop table t_retype;
+-- run
+
+-- The remedy the error should leave available: DROP DEFAULT, then the same retype
+-- succeeds.
+create table t_retype_fix (id integer primary key, n text null default 'abc');
+insert into t_retype_fix (id, n) values (1, '99');
+-- run
+
+alter table t_retype_fix alter column n set data type integer;
+-- error: Type conversion failed
+
+alter table t_retype_fix alter column n drop default;
+-- run
+
+alter table t_retype_fix alter column n set data type integer;
+-- run
+
+insert into t_retype_fix (id) values (2);
+select id, n from t_retype_fix order by id;
+→ [{"id":1,"n":99},{"id":2,"n":null}]
+
+drop table t_retype_fix;
+-- run
+
+-- A retype whose EXISTING default IS convertible to the new type still succeeds,
+-- and a later insert (using the post-retype default) stores it already converted.
+create table t_retype_ok (id integer primary key, n text default '7');
+insert into t_retype_ok (id, n) values (1, '42');
+-- run
+
+alter table t_retype_ok alter column n set data type integer;
+-- run
+
+insert into t_retype_ok (id) values (2);
+select id, n, typeof(n) as t from t_retype_ok order by id;
+→ [{"id":1,"n":42,"t":"integer"},{"id":2,"n":7,"t":"integer"}]
+
+drop table t_retype_ok;
+-- run
+
+-- ============================================================
+-- 3. A PRIMARY KEY column already refuses SET DATA TYPE — that refusal must win
+-- over the new default/type fold (checked first).
+-- ============================================================
+
+create table t_pk (id integer primary key default '5');
+-- run
+
+alter table t_pk alter column id set data type integer;
+-- error: PRIMARY KEY
+
+drop table t_pk;
+-- run
+
+-- ============================================================
+-- 4. A declarative migration that retypes a column AND replaces (or drops) its
+-- DEFAULT must still apply: the outgoing default is dropped BEFORE the retype, so
+-- a default only the OLD type could hold does not veto the migration. Only a
+-- migration that keeps an unconvertible default hits the §2 refusal.
+-- ============================================================
+
+create table t_mig (id integer primary key, n text default 'abc');
+insert into t_mig (id, n) values (1, '99');
+-- run
+
+declare schema main {
+	table t_mig {
+		id INTEGER PRIMARY KEY,
+		n INTEGER DEFAULT 0
+	}
+}
+
+-- run
+
+apply schema main;
+-- run
+
+insert into t_mig (id) values (2);
+select id, n, typeof(n) as t from t_mig order by id;
+→ [{"id":1,"n":99,"t":"integer"},{"id":2,"n":0,"t":"integer"}]
+
+drop table t_mig;
+-- run
+
+-- The same shape with the DEFAULT dropped rather than replaced.
+create table t_mig_drop (id integer primary key, n text default 'abc');
+insert into t_mig_drop (id, n) values (1, '99');
+-- run
+
+declare schema main {
+	table t_mig_drop {
+		id INTEGER PRIMARY KEY,
+		n INTEGER NULL
+	}
+}
+
+-- run
+
+apply schema main;
+-- run
+
+insert into t_mig_drop (id) values (2);
+select id, n from t_mig_drop order by id;
+→ [{"id":1,"n":99},{"id":2,"n":null}]
+
+drop table t_mig_drop;
+-- run

package/test/logic/41.16-fk-unenforceable.sqllogic

@@ -0,0 +1,364 @@
+-- 41.16-fk-unenforceable.sqllogic - a FOREIGN KEY that cannot be enforced must SAY SO
+--
+-- Two ways a declared foreign key ends up unenforceable, and what the engine owes the
+-- user in each case:
+--
+--  A. the parent table does not exist. MATCH SIMPLE still admits a row whose FK columns
+--     are NULL, and every other row is rejected — the behaviour is right and unchanged.
+--     What changes is the MESSAGE: it used to quote the engine-synthesized null-guard
+--     expression (`_fk_x_c (NEW.c is null or 0)`), which named nothing the user wrote.
+--     It now names the missing table, qualified by the schema it was looked up in —
+--     which is what makes the cross-schema mistake below diagnosable at all.
+--
+--  B. the child's FK column count does not line up with the parent key it references.
+--     Both FK check builders used to `continue` past such a key, leaving it declared but
+--     NOT ENFORCED: orphans accepted on the child, RESTRICT silently bypassed on the
+--     parent. The statement now fails instead.
+
+pragma foreign_keys = true;
+
+-- ===================================
+-- A1. missing parent — the error names the table, not the synthesized expression
+-- ===================================
+
+create table ghost_c (id integer primary key, c integer null references ghost_parent(refd));
+
+insert into ghost_c values (1, 5);
+-- error: CHECK constraint failed: _fk_ghost_c_c — referenced table 'main.ghost_parent' does not exist
+
+select count(*) as n from ghost_c;
+→ [{"n":0}]
+
+-- MATCH SIMPLE is untouched: a NULL FK column still satisfies the constraint
+insert into ghost_c values (2, null);
+
+select id, c from ghost_c order by id;
+→ [{"id":2,"c":null}]
+
+-- the UPDATE path reports the same thing
+update ghost_c set c = 7 where id = 2;
+-- error: referenced table 'main.ghost_parent' does not exist
+
+-- ===================================
+-- A2. composite FK, MATCH SIMPLE — one NULL column is enough to admit the row
+-- ===================================
+
+create table ghost_c2 (id integer primary key, x integer null, y integer null,
+	foreign key (x, y) references ghost_parent2(a, b));
+
+insert into ghost_c2 values (1, 1, null);
+insert into ghost_c2 values (2, null, null);
+
+select id, x, y from ghost_c2 order by id;
+→ [{"id":1,"x":1,"y":null},{"id":2,"x":null,"y":null}]
+
+-- both non-NULL: rejected, naming the missing parent
+insert into ghost_c2 values (3, 1, 2);
+-- error: referenced table 'main.ghost_parent2' does not exist
+
+-- ===================================
+-- A3. the immediate and the deferred report paths must agree
+--
+-- A child-side FK check is EXISTS-shaped, so it auto-defers to COMMIT under the default
+-- ABORT resolution; `or fail` forces evaluation at row time instead. Both must produce
+-- the same text (they share `constraintViolationMessage`).
+-- ===================================
+
+-- deferred: the failure surfaces at COMMIT of an explicit transaction
+begin;
+insert into ghost_c values (10, 5);
+commit;
+-- error: CHECK constraint failed: _fk_ghost_c_c — referenced table 'main.ghost_parent' does not exist
+
+select count(*) as n from ghost_c;
+→ [{"n":1}]
+
+-- immediate: `or fail` evaluates at row time
+insert or fail into ghost_c values (11, 5);
+-- error: CHECK constraint failed: _fk_ghost_c_c — referenced table 'main.ghost_parent' does not exist
+
+select count(*) as n from ghost_c;
+→ [{"n":1}]
+
+-- ===================================
+-- A4. `pragma foreign_keys = off` builds no checks at all — a missing parent must not
+--     start raising just because the message got better
+-- ===================================
+
+pragma foreign_keys = false;
+
+insert into ghost_c values (20, 5);
+
+select id, c from ghost_c order by id;
+→ [{"id":2,"c":null},{"id":20,"c":5}]
+
+delete from ghost_c where id = 20;
+
+pragma foreign_keys = true;
+
+drop table ghost_c2;
+drop table ghost_c;
+
+-- ===================================
+-- A5. resolution is PER PLAN, not cached at CREATE — forward references stay legal
+--
+-- `create table child` naming a not-yet-declared parent is documented as legal
+-- (docs/sql-ddl.md § Order Independence): restore-from-dump and mutually-referencing
+-- tables depend on it. So the child below must start enforcing the moment the parent
+-- appears, with no DDL on the child itself.
+-- ===================================
+
+create table fwd_c (id integer primary key, p integer null references fwd_p(pid));
+
+-- before the parent exists: rejected, naming it
+insert into fwd_c values (1, 1);
+-- error: referenced table 'main.fwd_p' does not exist
+
+create table fwd_p (pid integer primary key);
+insert into fwd_p values (1);
+
+-- now the very same insert succeeds — the check resolved on the LATER plan
+insert into fwd_c values (1, 1);
+
+select id, p from fwd_c order by id;
+→ [{"id":1,"p":1}]
+
+-- and a genuine orphan still fails with the ordinary FK message (parent exists)
+insert into fwd_c values (2, 99);
+-- error: CHECK constraint failed: _fk_fwd_c_p
+
+-- ===================================
+-- A6. …and the other direction: DROP the parent and the child goes back to reporting
+--     the missing table. Proves nothing was cached from creation.
+-- ===================================
+
+delete from fwd_c;
+drop table fwd_p;
+
+insert into fwd_c values (3, 1);
+-- error: referenced table 'main.fwd_p' does not exist
+
+drop table fwd_c;
+
+-- ===================================
+-- A7. cross-schema: an UNQUALIFIED parent name binds to the CHILD's OWN schema
+--
+-- That rule is deliberate and matches SQLite, where a foreign key cannot cross
+-- databases (docs/sql-constraints.md §7.6). The failure mode it produces is nasty:
+-- the parent plainly exists — in `main` — and the child in another schema silently
+-- refuses every row. Naming the schema in the message is what makes it diagnosable,
+-- and it points straight at the remedy: qualify the parent.
+-- ===================================
+
+declare schema xs {}
+apply schema xs;
+-- run
+
+create table main.xs_parent (pid integer primary key);
+insert into main.xs_parent values (1);
+
+-- unqualified `xs_parent` inside a table declared in `xs` means `xs.xs_parent`
+create table xs.xs_child (id integer primary key, p integer null references xs_parent(pid));
+
+insert into xs.xs_child values (1, 1);
+-- error: referenced table 'xs.xs_parent' does not exist
+
+-- qualifying the parent is the fix, and it works
+create table xs.xs_child2 (id integer primary key, p integer null references main.xs_parent(pid));
+
+insert into xs.xs_child2 values (1, 1);
+
+select id, p from xs.xs_child2 order by id;
+→ [{"id":1,"p":1}]
+
+-- and it is a real check, not a resolution that quietly stopped enforcing
+insert into xs.xs_child2 values (2, 99);
+-- error: CHECK constraint failed: _fk_xs_child2_p
+
+drop table xs.xs_child2;
+drop table xs.xs_child;
+drop table main.xs_parent;
+
+-- ===================================
+-- B1. column-count mismatch, child side — `references <parent>` with no column list
+--     defaults to the parent's PRIMARY KEY, which may have a different arity
+--
+-- The written-parent-column form (`references mp(a, b)`) is already refused at CREATE
+-- (41-fk-extended-targets.sqllogic case 5). The defaulted form cannot be: the parent may
+-- not exist yet, and its primary key can change afterwards. So it is caught at the
+-- enforcement seam instead — the statement fails rather than the key going unenforced.
+-- ===================================
+
+create table mm_p (a integer not null, b integer not null, primary key (a, b));
+create table mm_c (id integer primary key, x integer null references mm_p);
+
+insert into mm_p values (1, 2);
+
+insert into mm_c values (1, 1);
+-- error: Foreign key '_fk_mm_c_x' on table 'main.mm_c': 1 column(s) reference the primary key of 'main.mm_p', which has 2 column(s).
+
+select count(*) as n from mm_c;
+→ [{"n":0}]
+
+-- ===================================
+-- B2. …and the parent side. This is the part that used to be silent: a RESTRICT delete
+--     against the parent simply went through, because the parent-side builder skipped
+--     the malformed key exactly as the child-side one did.
+-- ===================================
+
+delete from mm_p where a = 1;
+-- error: Foreign key '_fk_mm_c_x' on table 'main.mm_c': 1 column(s) reference the primary key of 'main.mm_p', which has 2 column(s).
+
+select count(*) as n from mm_p;
+→ [{"n":1}]
+
+-- the parent-side UPDATE path too
+update mm_p set b = 3 where a = 1;
+-- error: Foreign key '_fk_mm_c_x' on table 'main.mm_c'
+
+select a, b from mm_p order by a;
+→ [{"a":1,"b":2}]
+
+-- reads are unaffected — a malformed key must not break introspection or queries
+select count(*) as n from mm_p join mm_c on mm_c.x = mm_p.a;
+→ [{"n":0}]
+
+drop table mm_c;
+drop table mm_p;
+
+-- ===================================
+-- B4. `pragma foreign_keys = off` silences arm B too — enforcement off means off on
+--     BOTH sides. The parent side is the one at risk: the runtime DML executor calls
+--     the batchability gate unconditionally (the pragma is re-checked at flush), so
+--     the gate must not raise while enforcement is off.
+-- ===================================
+
+pragma foreign_keys = false;
+
+create table offmm_p (a integer not null, b integer not null, primary key (a, b));
+create table offmm_c (id integer primary key, x integer null references offmm_p);
+
+insert into offmm_p values (1, 2);
+insert into offmm_c values (1, 1);
+
+-- child side: no checks are built at all
+select id, x from offmm_c order by id;
+→ [{"id":1,"x":1}]
+
+-- parent side, both ops: neither the plan gate nor the runtime gate may raise
+delete from offmm_p where a = 1;
+
+select count(*) as n from offmm_p;
+→ [{"n":0}]
+
+insert into offmm_p values (3, 4);
+update offmm_p set b = 5 where a = 3;
+
+select a, b from offmm_p order by a;
+→ [{"a":3,"b":5}]
+
+pragma foreign_keys = true;
+
+drop table offmm_c;
+drop table offmm_p;
+
+-- ===================================
+-- B5. arm B on the propagating actions — the CASCADE / SET NULL dispatch sites resolve
+--     the referenced columns separately from the RESTRICT pre-check, so a mismatched
+--     key must raise there too rather than cascading nowhere.
+-- ===================================
+
+create table cas_p (a integer not null, b integer not null, primary key (a, b));
+create table cas_c (id integer primary key, x integer null references cas_p on delete cascade);
+
+insert into cas_p values (1, 2);
+
+delete from cas_p where a = 1;
+-- error: Foreign key '_fk_cas_c_x' on table 'main.cas_c': 1 column(s) reference the primary key of 'main.cas_p', which has 2 column(s).
+
+select count(*) as n from cas_p;
+→ [{"n":1}]
+
+drop table cas_c;
+drop table cas_p;
+
+create table sn_p (a integer not null, b integer not null, primary key (a, b));
+create table sn_c (id integer primary key, x integer null references sn_p on update set null);
+
+insert into sn_p values (1, 2);
+
+update sn_p set b = 3 where a = 1;
+-- error: Foreign key '_fk_sn_c_x' on table 'main.sn_c': 1 column(s) reference the primary key of 'main.sn_p', which has 2 column(s).
+
+select a, b from sn_p order by a;
+→ [{"a":1,"b":2}]
+
+drop table sn_c;
+drop table sn_p;
+
+-- ===================================
+-- B6. `alter table … add constraint` reaches the same wording. The existing-row scan
+--     resolves the parent key itself, so it is a separate seam from the DML builders
+--     and used to phrase the mismatch its own way.
+-- ===================================
+
+create table alt_p (a integer not null, b integer not null, primary key (a, b));
+create table alt_c (id integer primary key, x integer null, y integer null);
+
+insert into alt_p values (1, 2);
+insert into alt_c values (1, 1, 2);
+
+alter table alt_c add constraint fk_alt foreign key (x) references alt_p;
+-- error: Foreign key 'fk_alt' on table 'main.alt_c': 1 column(s) reference the primary key of 'main.alt_p', which has 2 column(s).
+
+-- the refusal left nothing behind — the correctly-shaped ADD over the same rows works
+alter table alt_c add constraint fk_alt2 foreign key (x, y) references alt_p;
+
+insert into alt_c values (2, 9, 9);
+-- error: CHECK constraint failed: fk_alt2
+
+drop table alt_c;
+drop table alt_p;
+
+-- ===================================
+-- B3. the correctly-shaped composite case still works end to end, so B1/B2 are not
+--     rejecting every defaulted `references <parent>`
+-- ===================================
+
+create table ok_p (a integer not null, b integer not null, primary key (a, b));
+create table ok_c (id integer primary key, x integer null, y integer null, foreign key (x, y) references ok_p);
+
+insert into ok_p values (1, 2);
+insert into ok_c values (1, 1, 2);
+
+select id, x, y from ok_c order by id;
+→ [{"id":1,"x":1,"y":2}]
+
+insert into ok_c values (2, 9, 9);
+-- error: CHECK constraint failed: _fk_ok_c_x_y
+
+-- RESTRICT is genuinely enforced on the parent
+delete from ok_p where a = 1;
+-- error: FOREIGN KEY constraint failed
+
+select a, b from ok_p order by a;
+→ [{"a":1,"b":2}]
+
+drop table ok_c;
+drop table ok_p;
+
+-- single-column defaulted `references <parent>` — the ordinary shape
+create table ok1_p (pid integer primary key);
+create table ok1_c (id integer primary key, p integer null references ok1_p);
+
+insert into ok1_p values (1);
+insert into ok1_c values (1, 1);
+
+select id, p from ok1_c order by id;
+→ [{"id":1,"p":1}]
+
+insert into ok1_c values (2, 99);
+-- error: CHECK constraint failed: _fk_ok1_c_p
+
+drop table ok1_c;
+drop table ok1_p;