@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.11-deferred-fk-with-rename.sqllogic

@@ -0,0 +1,232 @@
+-- Deferred FK checks queued before an `alter table ... rename to` in the SAME
+-- transaction must still evaluate at commit, against the table's CURRENT name.
+-- Regression for: a queued check whose evaluator was compiled against the
+-- pre-rename name failed the COMMIT with an engine-level "connect failed"
+-- (memory) or a false constraint violation (store) instead of passing.
+
+pragma foreign_keys = true;
+
+-- ===================================
+-- 1. Renaming the PARENT after the deferred check is queued
+-- ===================================
+
+create table dr_p (id integer primary key);
+create table dr_c (id integer primary key,
+	pid integer null references dr_p(id) deferrable initially deferred);
+
+begin;
+insert into dr_c values (10, 1);   -- queues the deferred FK check against dr_p
+alter table dr_p rename to dr_p2;
+insert into dr_p2 values (1);      -- the parent row the check needs
+commit;
+
+select id, pid from dr_c order by id;
+→ [{"id":10,"pid":1}]
+
+select id from dr_p2 order by id;
+→ [{"id":1}]
+
+-- ===================================
+-- 2. Same shape, but the parent row never arrives — the check must still be
+--    evaluated and must REPORT the violation (not an internal error).
+-- ===================================
+
+create table dr_p3 (id integer primary key);
+create table dr_c3 (id integer primary key,
+	pid integer null references dr_p3(id) deferrable initially deferred);
+
+begin;
+insert into dr_c3 values (10, 1);
+alter table dr_p3 rename to dr_p4;
+commit;
+-- error: constraint
+
+select count(*) as cnt from dr_c3;
+→ [{"cnt":0}]
+
+-- ===================================
+-- 3. Self-referential deferred FK + rename (case 10 of
+--    41-fk-cascade-conflict-and-self-ref.sqllogic, plus a rename)
+-- ===================================
+
+create table dr_sd (id integer primary key,
+	pid integer null references dr_sd(id) deferrable initially deferred);
+
+begin;
+insert into dr_sd values (2, 1);   -- forward reference: parent not there yet
+alter table dr_sd rename to dr_sd2;
+insert into dr_sd2 values (1, null);
+commit;
+
+select id, pid from dr_sd2 order by id;
+→ [{"id":1,"pid":null},{"id":2,"pid":1}]
+
+-- ===================================
+-- 4. Renaming only the CHILD (the table the queued row belongs to)
+-- ===================================
+
+create table dr_p5 (id integer primary key);
+create table dr_c5 (id integer primary key,
+	pid integer null references dr_p5(id) deferrable initially deferred);
+
+begin;
+insert into dr_c5 values (10, 1);
+alter table dr_c5 rename to dr_c6;
+insert into dr_p5 values (1);
+commit;
+
+select id, pid from dr_c6 order by id;
+→ [{"id":10,"pid":1}]
+
+-- ===================================
+-- 5. Two renames of the same table in one transaction
+-- ===================================
+
+create table dr_p7 (id integer primary key);
+create table dr_c7 (id integer primary key,
+	pid integer null references dr_p7(id) deferrable initially deferred);
+
+begin;
+insert into dr_c7 values (10, 1);
+alter table dr_p7 rename to dr_p8;
+alter table dr_p8 rename to dr_p9;
+insert into dr_p9 values (1);
+commit;
+
+select id, pid from dr_c7 order by id;
+→ [{"id":10,"pid":1}]
+
+-- ===================================
+-- 6. Renaming a column the deferred check reads, on both sides
+-- ===================================
+
+create table dr_p10 (id integer primary key, tag text);
+create table dr_c10 (id integer primary key,
+	pid integer null references dr_p10(id) deferrable initially deferred);
+
+begin;
+insert into dr_c10 values (10, 1);
+alter table dr_p10 rename column id to key_id;
+alter table dr_c10 rename column pid to parent_id;
+insert into dr_p10 values (1, 'x');
+commit;
+
+select id, parent_id from dr_c10 order by id;
+→ [{"id":10,"parent_id":1}]
+
+-- ===================================
+-- 7. A freed name reused by a FRESH table in the same transaction must NOT be
+--    redirected — this is why the remap is per queued entry, not database-wide.
+-- ===================================
+
+create table dr_p11 (id integer primary key);
+create table dr_c11 (id integer primary key,
+	pid integer null references dr_p11(id) deferrable initially deferred);
+
+begin;
+insert into dr_c11 values (10, 1);
+alter table dr_p11 rename to dr_p12;   -- the FK now points at dr_p12
+insert into dr_p12 values (1);
+create table dr_p11 (id integer primary key);   -- fresh, unrelated table
+insert into dr_p11 values (99);
+commit;
+
+select id, pid from dr_c11 order by id;
+→ [{"id":10,"pid":1}]
+
+select id from dr_p11 order by id;
+→ [{"id":99}]
+
+-- ===================================
+-- 8. …and renaming that reused name again must still not drag the parked check
+--    along: the parked entry already knows where ITS table went.
+-- ===================================
+
+create table dr_p13 (id integer primary key);
+create table dr_c13 (id integer primary key,
+	pid integer null references dr_p13(id) deferrable initially deferred);
+
+begin;
+insert into dr_c13 values (10, 1);
+alter table dr_p13 rename to dr_p14;            -- parked check now reads dr_p14
+insert into dr_p14 values (1);                  -- the parent row it needs
+create table dr_p13 (id integer primary key);   -- fresh table takes the freed name
+insert into dr_p13 values (99);
+alter table dr_p13 rename to dr_p15;            -- must NOT re-point the parked check
+commit;
+
+select id, pid from dr_c13 order by id;
+→ [{"id":10,"pid":1}]
+
+select id from dr_p14 order by id;
+→ [{"id":1}]
+
+select id from dr_p15 order by id;
+→ [{"id":99}]
+
+-- ===================================
+-- 9. Cross-schema: the remap keys are `<schema>.<name>`, so a rename in ONE
+--    schema must never follow a same-named table in another. Here the parked
+--    check reads `s2.dr_x`, which is renamed to `dr_x2`; renaming the unrelated
+--    `main.dr_x2` afterwards must leave the parked check pointing at `s2.dr_x2`.
+-- ===================================
+
+declare schema s2 {}
+apply schema s2;
+-- run
+
+create table s2.dr_x (id integer primary key);
+create table dr_x2 (id integer primary key);   -- main, colliding bare name
+create table dr_cx (id integer primary key,
+	pid integer null references s2.dr_x(id) deferrable initially deferred);
+
+begin;
+insert into dr_cx values (10, 1);
+alter table s2.dr_x rename to dr_x2;   -- parked check now reads s2.dr_x2
+insert into s2.dr_x2 values (1);       -- the parent row it needs
+alter table dr_x2 rename to dr_x3;     -- main.dr_x2 — must NOT drag the check along
+commit;
+
+select id, pid from dr_cx order by id;
+→ [{"id":10,"pid":1}]
+
+select id from s2.dr_x2 order by id;
+→ [{"id":1}]
+
+-- ===================================
+-- 10. The other deferred shape: a CHECK containing a subquery is auto-deferred
+--     (constraint-builder's `needsDeferred`), so this parks a check that reads
+--     `dr_lookup` — a table neither side of any FK — and then renames it.
+--
+--     The value the check needs is inserted into the RENAMED table, after the
+--     rename and before commit. This discriminates the remap for real: the
+--     check is genuinely deferred to COMMIT and re-reads the live table there
+--     (`bug-deferred-subquery-check-reads-stale-state`), so a broken
+--     `notifyTableRename` remap — or a regression back to immediate
+--     evaluation — would read the wrong table state and reject 'z', which
+--     only exists under the table's post-rename name.
+-- ===================================
+
+create table dr_lookup (code text primary key);
+insert into dr_lookup values ('a'), ('b');
+create table dr_ck (id integer primary key, code text,
+	constraint dr_ck_code check (code in (select code from dr_lookup)));
+
+begin;
+insert into dr_ck values (1, 'z');
+alter table dr_lookup rename to dr_lookup2;
+insert into dr_lookup2 values ('z');
+commit;
+
+select id, code from dr_ck order by id;
+→ [{"id":1,"code":"z"}]
+
+-- …and the violation is still REPORTED as a constraint failure across a rename.
+begin;
+insert into dr_ck values (2, 'zzz');
+alter table dr_lookup2 rename to dr_lookup3;
+commit;
+-- error: constraint
+
+select count(*) as cnt from dr_ck;
+→ [{"cnt":1}]

package/test/logic/41.12-alter-default-coercion.sqllogic

@@ -0,0 +1,200 @@
+-- ALTER backfill DEFAULTs are converted to the column's declared type.
+--
+-- A backfilled cell must be indistinguishable from the cell a fresh INSERT under
+-- the same DEFAULT would produce — same value, same typeof — for the literal
+-- ADD COLUMN path, the per-row `new.<col>` evaluator path, and the SET NOT NULL
+-- backfill. Runs under both the memory module (`yarn test`) and the store module
+-- (`yarn test:store`); `typeof(...)` reads the stored value, so it is
+-- module-agnostic.
+
+-- ============================================================
+-- 1. ADD COLUMN, literal default whose type differs from the column's
+-- ============================================================
+
+create table t_lit (a integer primary key, b integer);
+insert into t_lit values (1, 10);
+-- run
+
+alter table t_lit add column n integer default '7';
+-- run
+
+-- Row 2 is inserted AFTER the ALTER, so the same DEFAULT applies through the
+-- ordinary write path. Both rows must agree on value and on typeof.
+insert into t_lit (a, b) values (2, 20);
+-- run
+
+select a, n, typeof(n) as t from t_lit order by a;
+→ [{"a":1,"n":7,"t":"integer"},{"a":2,"n":7,"t":"integer"}]
+
+drop table t_lit;
+-- run
+
+-- Signed numeric default (a UnaryExpr, not a bare literal) on a REAL column.
+create table t_neg (a integer primary key, b integer);
+insert into t_neg values (1, 10);
+-- run
+
+alter table t_neg add column n real default -123.0;
+-- run
+
+insert into t_neg (a, b) values (2, 20);
+-- run
+
+-- `typeof` reports the stored VALUE's storage class, and an integral REAL reads back
+-- as 'integer' — on both rows, which is the point: backfill and insert agree.
+select a, n, typeof(n) as t from t_neg order by a;
+→ [{"a":1,"n":-123,"t":"integer"},{"a":2,"n":-123,"t":"integer"}]
+
+drop table t_neg;
+-- run
+
+-- ============================================================
+-- 2. ADD COLUMN, literal default on a JSON column
+--
+-- The DEFAULT's raw source text ('"abc"') is not the stored form any write path
+-- produces — the stored form is the parsed JSON scalar (abc).
+-- ============================================================
+
+create table t_json (a integer primary key, b integer);
+insert into t_json values (1, 10);
+-- run
+
+alter table t_json add column n json default '"abc"';
+-- run
+
+insert into t_json (a, b) values (2, 20);
+-- run
+
+select a, n from t_json order by a;
+→ [{"a":1,"n":"abc"},{"a":2,"n":"abc"}]
+
+drop table t_json;
+-- run
+
+-- ============================================================
+-- 2b. ADD COLUMN, literal default on temporal columns
+--
+-- A temporal type's parse CANONICALIZES, so the backfilled cell must hold the
+-- canonical spelling (the one `set data type` rewrites to and an INSERT stores),
+-- not the DEFAULT's raw source text.
+-- ============================================================
+
+create table t_temporal (a integer primary key, b integer);
+insert into t_temporal values (1, 10);
+-- run
+
+alter table t_temporal add column d date default '2024-06-05T00:00:00Z';
+-- run
+
+alter table t_temporal add column sp timespan default '1 hour';
+-- run
+
+insert into t_temporal (a, b) values (2, 20);
+-- run
+
+select a, d, sp from t_temporal order by a;
+→ [{"a":1,"d":"2024-06-05","sp":"PT1H"},{"a":2,"d":"2024-06-05","sp":"PT1H"}]
+
+drop table t_temporal;
+-- run
+
+-- ============================================================
+-- 3. ADD COLUMN, per-row `new.<col>` evaluator default across types
+-- ============================================================
+
+create table t_eval (a integer primary key, b text);
+insert into t_eval values (1, '7');
+-- run
+
+alter table t_eval add column n integer default (new.b);
+-- run
+
+insert into t_eval (a, b) values (2, '20');
+-- run
+
+select a, n, typeof(n) as t from t_eval order by a;
+→ [{"a":1,"n":7,"t":"integer"},{"a":2,"n":20,"t":"integer"}]
+
+drop table t_eval;
+-- run
+
+-- ============================================================
+-- 4. Regression guard: identity case must NOT be re-converted
+--
+-- When the default expression's static type already IS the new column's type,
+-- the evaluated value is ALREADY in stored form and must be copied verbatim.
+-- JSON's parse reads a plain JS string as JSON *source*, so a blanket coercion
+-- would turn the stored text `9` into the number 9 and throw on stored `abc`.
+-- ============================================================
+
+create table t_ident (a integer primary key, j json);
+insert into t_ident values (1, '"abc"'), (2, '9');
+-- run
+
+select a, j from t_ident order by a;
+→ [{"a":1,"j":"abc"},{"a":2,"j":9}]
+
+alter table t_ident add column k json default (new.j);
+-- run
+
+select a, k from t_ident order by a;
+→ [{"a":1,"k":"abc"},{"a":2,"k":9}]
+
+drop table t_ident;
+-- run
+
+-- ============================================================
+-- 5. ALTER COLUMN ... SET NOT NULL backfills the converted DEFAULT
+-- ============================================================
+
+create table t_snn (a integer primary key, b integer null default '5');
+insert into t_snn (a, b) values (1, null);
+-- run
+
+alter table t_snn alter column b set not null;
+-- run
+
+select a, b, typeof(b) as t from t_snn order by a;
+→ [{"a":1,"b":5,"t":"integer"}]
+
+-- The backfilled cell matches what an INSERT letting the DEFAULT apply stores.
+insert into t_snn (a) values (2);
+-- run
+
+select a, b, typeof(b) as t from t_snn order by a;
+→ [{"a":1,"b":5,"t":"integer"},{"a":2,"b":5,"t":"integer"}]
+
+drop table t_snn;
+-- run
+
+-- ============================================================
+-- 6. An unconvertible literal default rejects the ALTER
+--
+-- Same MISMATCH the equivalent INSERT raises, and — deliberately — regardless of
+-- how many rows the table happens to hold, so DDL acceptance does not depend on
+-- the data.
+-- ============================================================
+
+create table t_bad (a integer primary key);
+insert into t_bad values (1);
+-- run
+
+alter table t_bad add column n integer default 'abc';
+-- error: Type conversion failed
+
+-- The column was not added.
+select * from t_bad order by a;
+→ [{"a":1}]
+
+drop table t_bad;
+-- run
+
+-- Empty table: same rejection.
+create table t_bad_empty (a integer primary key);
+-- run
+
+alter table t_bad_empty add column n integer default 'abc';
+-- error: Type conversion failed
+
+drop table t_bad_empty;
+-- run