@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/41.13-alter-add-column-generated-backfill.sqllogic

@@ -0,0 +1,566 @@
+-- ALTER TABLE ADD COLUMN ... GENERATED ALWAYS AS backfills the existing rows.
+--
+-- A generated column's value is a pure function of its row, so adding one to a
+-- populated table must compute it for the rows that are already there — the same
+-- value the identical declaration in CREATE TABLE would produce, and the same value
+-- a fresh INSERT produces afterwards. Anything the recomputation cannot honour
+-- (NOT NULL left NULL, an inline CHECK violated) rejects the whole ALTER and leaves
+-- the table exactly as it was.
+--
+-- Runs under both the memory module (`yarn test`) and the store module
+-- (`yarn test:store`).
+
+-- ============================================================
+-- 1. Every spelling backfills: bare, VIRTUAL, STORED
+--
+-- VIRTUAL and STORED are not distinguished by this engine — a generated column's
+-- value is materialized at write time either way — so all three must agree.
+-- ============================================================
+
+create table t_bare (id integer primary key, v integer);
+insert into t_bare values (1, 5);
+-- run
+
+alter table t_bare add column g integer generated always as (v * 2);
+-- run
+
+-- Row 2 arrives AFTER the ALTER, through the ordinary write path. The backfilled
+-- row and the inserted row must agree.
+insert into t_bare (id, v) values (2, 7);
+-- run
+
+select id, v, g from t_bare order by id;
+→ [{"id":1,"v":5,"g":10},{"id":2,"v":7,"g":14}]
+
+drop table t_bare;
+-- run
+
+create table t_virtual (id integer primary key, v integer);
+insert into t_virtual values (1, 5);
+-- run
+
+alter table t_virtual add column g integer null generated always as (v * 2) virtual;
+-- run
+
+insert into t_virtual (id, v) values (2, 7);
+-- run
+
+select id, v, g from t_virtual order by id;
+→ [{"id":1,"v":5,"g":10},{"id":2,"v":7,"g":14}]
+
+drop table t_virtual;
+-- run
+
+create table t_stored (id integer primary key, v integer);
+insert into t_stored values (1, 5);
+-- run
+
+alter table t_stored add column g integer null generated always as (v * 2) stored;
+-- run
+
+insert into t_stored (id, v) values (2, 7);
+-- run
+
+select id, v, g from t_stored order by id;
+→ [{"id":1,"v":5,"g":10},{"id":2,"v":7,"g":14}]
+
+-- The column reports as generated in the catalog (1 = VIRTUAL, 2 = STORED). The
+-- distinction is informational only — both spellings materialize at write time.
+select name, "generated" from table_info('t_stored') where name = 'g';
+→ [{"name":"g","generated":2}]
+
+drop table t_stored;
+-- run
+
+-- ============================================================
+-- 2. A constant generated expression still backfills
+--
+-- A generated column has no DEFAULT to bulk-write, so the literal-folding
+-- shortcut the DEFAULT path takes must NOT apply here — folding it would leave
+-- every existing row NULL.
+-- ============================================================
+
+create table t_const (id integer primary key, v integer);
+insert into t_const values (1, 5);
+-- run
+
+alter table t_const add column g integer null generated always as (2);
+-- run
+
+insert into t_const (id, v) values (2, 7);
+-- run
+
+select id, g from t_const order by id;
+→ [{"id":1,"g":2},{"id":2,"g":2}]
+
+drop table t_const;
+-- run
+
+-- ============================================================
+-- 3. A generated expression over an existing generated column
+--
+-- `h` is already materialized in every stored row, so `g` reads it during the
+-- backfill exactly as it would during an INSERT.
+-- ============================================================
+
+create table t_chain (id integer primary key, v integer, h integer generated always as (v + 1));
+insert into t_chain (id, v) values (1, 5);
+-- run
+
+alter table t_chain add column g integer null generated always as (h * 10);
+-- run
+
+insert into t_chain (id, v) values (2, 7);
+-- run
+
+select id, v, h, g from t_chain order by id;
+→ [{"id":1,"v":5,"h":6,"g":60},{"id":2,"v":7,"h":8,"g":80}]
+
+drop table t_chain;
+-- run
+
+-- ============================================================
+-- 4. Type conversion: the backfilled cell matches what an INSERT stores
+-- ============================================================
+
+create table t_coerce (id integer primary key, v text);
+insert into t_coerce values (1, '7');
+-- run
+
+alter table t_coerce add column g integer null generated always as (v || '0');
+-- run
+
+insert into t_coerce (id, v) values (2, '2');
+-- run
+
+select id, g, typeof(g) as t from t_coerce order by id;
+→ [{"id":1,"g":70,"t":"integer"},{"id":2,"g":20,"t":"integer"}]
+
+drop table t_coerce;
+-- run
+
+-- ============================================================
+-- 5. NOT NULL generated: accepted when the expression is total ...
+-- ============================================================
+
+create table t_nn (id integer primary key, v integer);
+insert into t_nn values (1, 5), (2, 7);
+-- run
+
+alter table t_nn add column g integer not null generated always as (v * 2);
+-- run
+
+insert into t_nn (id, v) values (3, 9);
+-- run
+
+select id, g from t_nn order by id;
+→ [{"id":1,"g":10},{"id":2,"g":14},{"id":3,"g":18}]
+
+drop table t_nn;
+-- run
+
+-- ... and rejected, table untouched, when it yields NULL for an existing row.
+create table t_nn_bad (id integer primary key, v integer null);
+insert into t_nn_bad values (1, 5), (2, null);
+-- run
+
+alter table t_nn_bad add column g integer not null generated always as (v * 2);
+-- error: NOT NULL constraint failed
+
+-- The ALTER was reverted whole: the column is gone and the rows are unchanged.
+select * from t_nn_bad order by id;
+→ [{"id":1,"v":5},{"id":2,"v":null}]
+
+drop table t_nn_bad;
+-- run
+
+-- ============================================================
+-- 6. An inline CHECK over the new column is enforced per backfilled row
+--
+-- Before the backfill existed the CHECK saw NULL and `not (null > 100)` is NULL,
+-- so the violation went unnoticed. With a real value the ALTER must reject.
+-- ============================================================
+
+create table t_check (id integer primary key, v integer);
+insert into t_check values (1, 5);
+-- run
+
+alter table t_check add column g integer null generated always as (v * 2) check (g > 100);
+-- error: CHECK constraint failed
+
+select * from t_check order by id;
+→ [{"id":1,"v":5}]
+
+-- The same declaration whose values satisfy the CHECK is accepted.
+alter table t_check add column g integer null generated always as (v * 2) check (g > 0);
+-- run
+
+select id, g from t_check order by id;
+→ [{"id":1,"g":10}]
+
+drop table t_check;
+-- run
+
+-- ============================================================
+-- 7. A non-deterministic generated expression is rejected at ALTER time
+--
+-- Matches the DEFAULT arm, which validates at plan-build regardless of row count,
+-- rather than deferring the failure to the next INSERT.
+-- ============================================================
+
+create table t_nondet (id integer primary key, v integer);
+insert into t_nondet values (1, 5);
+-- run
+
+alter table t_nondet add column g integer null generated always as (random());
+-- error: Non-deterministic expression not allowed in GENERATED ALWAYS AS
+
+select * from t_nondet order by id;
+→ [{"id":1,"v":5}]
+
+drop table t_nondet;
+-- run
+
+-- Empty table: same rejection, so DDL acceptance does not depend on the data.
+create table t_nondet_empty (id integer primary key, v integer);
+-- run
+
+alter table t_nondet_empty add column g integer null generated always as (random());
+-- error: Non-deterministic expression not allowed in GENERATED ALWAYS AS
+
+drop table t_nondet_empty;
+-- run
+
+-- ============================================================
+-- 8. A bad generated expression is reported the way CREATE TABLE reports it
+--
+-- The expression is compiled against a scope holding only the EXISTING columns, so
+-- without a pre-flight an unknown name — or the new column's own name — would surface
+-- as a bare "Column not found". Both must keep naming the generated column.
+-- ============================================================
+
+create table t_badref (id integer primary key, v integer);
+insert into t_badref values (1, 5);
+-- run
+
+alter table t_badref add column g integer null generated always as (nope * 2);
+-- error: Column 'nope' referenced by generated column 'g' not found in table 't_badref'
+
+alter table t_badref add column g integer null generated always as (g + 1);
+-- error: Cyclic dependency in generated columns: 'g'
+
+select * from t_badref order by id;
+→ [{"id":1,"v":5}]
+
+drop table t_badref;
+-- run
+
+-- ============================================================
+-- 9. The declarative route (declare schema + apply schema)
+--
+-- The differ emits the same ADD COLUMN through the same emitter, so a generated
+-- column declared onto a populated table backfills identically.
+-- ============================================================
+
+declare schema main {
+	table t_decl {
+		id INTEGER PRIMARY KEY,
+		v INTEGER
+	}
+}
+-- run
+
+apply schema main;
+-- run
+
+insert into t_decl values (1, 5);
+-- run
+
+declare schema main {
+	table t_decl {
+		id INTEGER PRIMARY KEY,
+		v INTEGER,
+		g INTEGER NULL GENERATED ALWAYS AS (v * 2)
+	}
+}
+-- run
+
+apply schema main;
+-- run
+
+insert into t_decl (id, v) values (2, 7);
+-- run
+
+select id, v, g from t_decl order by id;
+→ [{"id":1,"v":5,"g":10},{"id":2,"v":7,"g":14}]
+
+drop table t_decl;
+-- run
+
+-- ============================================================
+-- 10. Rows staged in the open transaction backfill too
+--
+-- The ALTER runs while the transaction holds an uncommitted row. Both the committed
+-- row and the staged one must carry the computed value, and the staged row must
+-- still commit. (Memory stages in its transaction layers, the store in the isolation
+-- overlay; both run the same evaluator over the staged rows.)
+-- ============================================================
+
+create table t_staged (id integer primary key, v integer);
+insert into t_staged values (1, 5);
+-- run
+
+begin;
+-- run
+
+insert into t_staged values (2, 7);
+-- run
+
+alter table t_staged add column g integer null generated always as (v * 2);
+-- run
+
+select id, v, g from t_staged order by id;
+→ [{"id":1,"v":5,"g":10},{"id":2,"v":7,"g":14}]
+
+insert into t_staged (id, v) values (3, 9);
+-- run
+
+commit;
+-- run
+
+select id, v, g from t_staged order by id;
+→ [{"id":1,"v":5,"g":10},{"id":2,"v":7,"g":14},{"id":3,"v":9,"g":18}]
+
+drop table t_staged;
+-- run
+
+-- ============================================================
+-- 11. An inline UNIQUE over the new column sees the backfilled values
+--
+-- The constraint-install loop runs after the backfill, so the covering structure is
+-- built over real computed values — distinct ones are accepted, colliding ones reject
+-- the whole ALTER.
+-- ============================================================
+
+create table t_uniq (id integer primary key, v integer);
+insert into t_uniq values (1, 5), (2, 6);
+-- run
+
+alter table t_uniq add column g integer null generated always as (v * 2) unique;
+-- run
+
+select id, g from t_uniq order by id;
+→ [{"id":1,"g":10},{"id":2,"g":12}]
+
+drop table t_uniq;
+-- run
+
+create table t_uniq_bad (id integer primary key, v integer);
+insert into t_uniq_bad values (1, 5), (2, 5);
+-- run
+
+alter table t_uniq_bad add column g integer null generated always as (v * 2) unique;
+-- error: UNIQUE constraint failed
+
+-- Reverted whole: the column is gone and the rows are unchanged.
+select * from t_uniq_bad order by id;
+→ [{"id":1,"v":5},{"id":2,"v":5}]
+
+drop table t_uniq_bad;
+-- run
+
+-- ============================================================
+-- 12. A generated column whose name is already taken is a DUPLICATE, not a cycle
+--
+-- The self-reference rejection in section 8 must not swallow this: `v` here resolves
+-- to the existing sibling, and the real problem is that the table already has a `v`.
+-- ============================================================
+
+create table t_dup (id integer primary key, v integer);
+insert into t_dup values (1, 5);
+-- run
+
+alter table t_dup add column v integer null generated always as (v * 2);
+-- error: Column 'v' already exists in table 't_dup'
+
+alter table t_dup add column v integer null generated always as (id + 1);
+-- error: Column 'v' already exists in table 't_dup'
+
+select * from t_dup order by id;
+→ [{"id":1,"v":5}]
+
+drop table t_dup;
+-- run
+
+-- ============================================================
+-- 13. The added column is a first-class generated column afterwards
+--
+-- Backfilling is only half the job: the ALTER must also register the column in the
+-- table's generated-column graph, so UPDATEing a source column recomputes it and
+-- writing to it directly is refused — exactly as for a CREATE TABLE-declared one.
+-- ============================================================
+
+create table t_after (id integer primary key, v integer);
+insert into t_after values (1, 5);
+-- run
+
+alter table t_after add column g integer null generated always as (v * 2);
+-- run
+
+update t_after set v = 20 where id = 1;
+-- run
+
+select id, v, g from t_after order by id;
+→ [{"id":1,"v":20,"g":40}]
+
+update t_after set g = 1 where id = 1;
+-- error: Cannot UPDATE generated column 'g'
+
+insert into t_after (id, v, g) values (2, 3, 99);
+-- error: Cannot INSERT into generated column 'g'
+
+select id, v, g from t_after order by id;
+→ [{"id":1,"v":20,"g":40}]
+
+drop table t_after;
+-- run
+
+-- ============================================================
+-- 14. Every accepted spelling backfills AND stays writable afterwards
+--
+-- The declaration this ALTER accepts must be one every subsequent INSERT accepts:
+-- the backfill and the write path compile the same stored body, through the same
+-- builder (`planner/building/generated-column-scope.ts`). `new.<col>` is the arm
+-- that used to break — the ALTER accepted it and backfilled correctly, and then
+-- every INSERT afterwards failed with `new.<col> isn't a column`, leaving a table
+-- that could never gain another row.
+--
+-- Each arm: backfill an existing row, insert a new one, update the source column.
+-- All three must agree. The CREATE TABLE side of the same matrix lives in
+-- 41-generated-columns.sqllogic.
+-- ============================================================
+
+create table t_sp_bare (id integer primary key, a integer);
+insert into t_sp_bare values (1, 3);
+-- run
+
+alter table t_sp_bare add column g integer generated always as (a + 1);
+-- run
+
+insert into t_sp_bare (id, a) values (2, 5);
+update t_sp_bare set a = 10 where id = 1;
+-- run
+
+select id, a, g from t_sp_bare order by id;
+→ [{"id":1,"a":10,"g":11},{"id":2,"a":5,"g":6}]
+
+drop table t_sp_bare;
+-- run
+
+create table t_sp_tbl (id integer primary key, a integer);
+insert into t_sp_tbl values (1, 3);
+-- run
+
+alter table t_sp_tbl add column g integer generated always as (t_sp_tbl.a + 1);
+-- run
+
+insert into t_sp_tbl (id, a) values (2, 5);
+update t_sp_tbl set a = 10 where id = 1;
+-- run
+
+select id, a, g from t_sp_tbl order by id;
+→ [{"id":1,"a":10,"g":11},{"id":2,"a":5,"g":6}]
+
+drop table t_sp_tbl;
+-- run
+
+create table t_sp_sch (id integer primary key, a integer);
+insert into t_sp_sch values (1, 3);
+-- run
+
+alter table t_sp_sch add column g integer generated always as (main.t_sp_sch.a + 1);
+-- run
+
+insert into t_sp_sch (id, a) values (2, 5);
+update t_sp_sch set a = 10 where id = 1;
+-- run
+
+select id, a, g from t_sp_sch order by id;
+→ [{"id":1,"a":10,"g":11},{"id":2,"a":5,"g":6}]
+
+drop table t_sp_sch;
+-- run
+
+create table t_sp_new (id integer primary key, a integer);
+insert into t_sp_new values (1, 3);
+-- run
+
+alter table t_sp_new add column g integer generated always as (new.a + 1);
+-- run
+
+insert into t_sp_new (id, a) values (2, 5);
+update t_sp_new set a = 10 where id = 1;
+-- run
+
+select id, a, g from t_sp_new order by id;
+→ [{"id":1,"a":10,"g":11},{"id":2,"a":5,"g":6}]
+
+drop table t_sp_new;
+-- run
+
+-- ============================================================
+-- 15. A second ADD COLUMN reading the first added generated column
+--
+-- `new.g1` names the freshly computed g1, exactly as a bare `g1` does — at
+-- backfill time and on every write afterwards.
+-- ============================================================
+
+create table t_sp_chain (id integer primary key, a integer);
+insert into t_sp_chain values (1, 5);
+-- run
+
+alter table t_sp_chain add column g1 integer generated always as (a * 2);
+alter table t_sp_chain add column g2 integer generated always as (new.g1 + 1);
+-- run
+
+select id, a, g1, g2 from t_sp_chain order by id;
+→ [{"id":1,"a":5,"g1":10,"g2":11}]
+
+insert into t_sp_chain (id, a) values (2, 7);
+update t_sp_chain set a = 10 where id = 1;
+-- run
+
+select id, a, g1, g2 from t_sp_chain order by id;
+→ [{"id":1,"a":10,"g1":20,"g2":21},{"id":2,"a":7,"g1":14,"g2":15}]
+
+drop table t_sp_chain;
+-- run
+
+-- ============================================================
+-- 16. A declared COLLATE applies inside a backfilled generated body
+--
+-- The backfill compiles the body through the same builder the write paths use,
+-- which resolves each column reference at its DECLARED type — collation
+-- included. So an existing row backfills by the same comparison a later INSERT
+-- computes with.
+-- ============================================================
+
+create table t_sp_coll (id integer primary key, a text collate nocase);
+insert into t_sp_coll values (1, 'abc');
+-- run
+
+alter table t_sp_coll add column g integer generated always as (case when a = 'ABC' then 1 else 0 end);
+-- run
+
+select id, a, g from t_sp_coll order by id;
+→ [{"id":1,"a":"abc","g":1}]
+
+insert into t_sp_coll (id, a) values (2, 'AbC');
+insert into t_sp_coll (id, a) values (3, 'abd');
+-- run
+
+select id, g from t_sp_coll order by id;
+→ [{"id":1,"g":1},{"id":2,"g":1},{"id":3,"g":0}]
+
+drop table t_sp_coll;
+-- run

package/test/logic/41.14-alter-add-column-subquery-backfill.sqllogic

@@ -0,0 +1,129 @@
+-- ALTER TABLE ADD COLUMN's DEFAULT / GENERATED ALWAYS AS / inline CHECK may read another
+-- table (a correlated or uncorrelated subquery), and the backfill still runs per row.
+--
+-- Regression for bug-alter-add-column-relation-default-fails-to-emit: `AlterTableNode`
+-- held the backfill and CHECK expressions off the child-node graph the optimizer walks
+-- (`getChildren()`/`withChildren()`), so a subquery inside either reached the runtime
+-- unphysicalized and the whole ALTER errored — a simple expression default (nothing to
+-- rewrite) worked, so this was invisible until the default read another table.
+--
+-- Runs under both the memory module (`yarn test`) and the store module (`yarn
+-- test:store`).
+
+create table d (k integer);
+insert into d values (1);
+-- run
+
+create table a1 (id integer primary key);
+insert into a1 values (1);
+-- run
+
+-- 1. Uncorrelated aggregate subquery DEFAULT.
+alter table a1 add column w integer default (select count(*) from d);
+-- run
+
+select id, w from a1 order by id;
+→ [{"id":1,"w":1}]
+
+-- 2. Uncorrelated scalar subquery DEFAULT (LIMIT 1).
+alter table a1 add column x integer default ((select k from d limit 1));
+-- run
+
+select id, x from a1 order by id;
+→ [{"id":1,"x":1}]
+
+-- 3. GENERATED ALWAYS AS over a subquery — always a per-row backfill (a generated
+-- column has no `defaultValue` for the module to bulk-write).
+alter table a1 add column g integer generated always as ((select count(*) from d));
+-- run
+
+select id, g from a1 order by id;
+→ [{"id":1,"g":1}]
+
+-- 4. A per-row DEFAULT (`new.id`) with an inline CHECK that itself reads another
+-- table — accepted when the CHECK passes.
+alter table a1 add column z integer default (new.id) check ((select count(*) from d) = 1);
+-- run
+
+select id, z from a1 order by id;
+→ [{"id":1,"z":1}]
+
+-- 5. Same shape, CHECK fails against the backfilled row — the whole ALTER is
+-- rejected and the table is left exactly as it was (no `zz` column).
+alter table a1 add column zz integer default (new.id) check ((select count(*) from d) = 99);
+-- error: CHECK constraint failed
+
+select * from a1 order by id;
+→ [{"id":1,"w":1,"x":1,"g":1,"z":1}]
+
+drop table a1;
+-- run
+
+-- ===== Multi-row, correlated =====
+-- Every arm above has a single existing row, so it cannot tell a genuine per-row
+-- evaluation from one evaluation replayed for every row. These use three rows and a
+-- subquery correlated to the row being backfilled, so a once-only (or cached) evaluation
+-- shows up as three identical values.
+
+create table dd (k integer, v integer);
+insert into dd values (1, 10), (2, 20), (3, 30);
+-- run
+
+create table a2 (id integer primary key);
+insert into a2 values (1), (2), (3);
+-- run
+
+-- 6. Correlated subquery DEFAULT — a distinct value per existing row.
+alter table a2 add column w integer default ((select v from dd where dd.k = new.id limit 1));
+-- run
+
+select id, w from a2 order by id;
+→ [{"id":1,"w":10},{"id":2,"w":20},{"id":3,"w":30}]
+
+-- 7. Correlated subquery inside the CHECK, evaluated against each backfilled row.
+alter table a2 add column x integer default (new.id) check ((select v from dd where dd.k = new.id limit 1) = new.id * 10);
+-- run
+
+select id, x from a2 order by id;
+→ [{"id":1,"x":1},{"id":2,"x":2},{"id":3,"x":3}]
+
+-- 8. TWO inline CHECKs alongside the backfill — three optimizer children, so the
+-- emitter's slot cursor (backfill, then each predicate in order) has to walk past more
+-- than one predicate. The SECOND one fails, which a slot-order bug would misreport.
+alter table a2 add column yy integer default (new.id) check ((select count(*) from dd) = 3) check ((select v from dd where dd.k = new.id limit 1) = 999);
+-- error: CHECK constraint failed
+
+-- 9. Same two CHECKs, both true — accepted.
+alter table a2 add column y integer default (new.id) check ((select count(*) from dd) = 3) check ((select v from dd where dd.k = new.id limit 1) = new.id * 10);
+-- run
+
+select id, y from a2 order by id;
+→ [{"id":1,"y":1},{"id":2,"y":2},{"id":3,"y":3}]
+
+-- 10. GENERATED ALWAYS AS over a correlated subquery, inner reference QUALIFIED (`dd.v`).
+alter table a2 add column g integer generated always as ((select dd.v from dd where dd.k = id limit 1));
+-- run
+
+select id, g from a2 order by id;
+→ [{"id":1,"g":10},{"id":2,"g":20},{"id":3,"g":30}]
+
+-- 11. Same shape, inner reference UNQUALIFIED (`v`): the subquery's own FROM binds it,
+-- so the generated-column reference analysis leaves it to that source instead of
+-- reading it as a (missing) column of this table.
+alter table a2 add column h integer generated always as ((select v from dd where dd.k = id limit 1));
+-- run
+
+select id, h from a2 order by id;
+→ [{"id":1,"h":10},{"id":2,"h":20},{"id":3,"h":30}]
+
+select * from a2 order by id;
+→ [{"id":1,"w":10,"x":1,"y":1,"g":10,"h":10},{"id":2,"w":20,"x":2,"y":2,"g":20,"h":20},{"id":3,"w":30,"x":3,"y":3,"g":30,"h":30}]
+
+drop table a2;
+-- run
+
+drop table dd;
+-- run
+
+drop table d;
+-- run