@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/41-generated-column-scope.sqllogic

@@ -0,0 +1,329 @@
+-- Scope-aware reference analysis for GENERATED ALWAYS AS expressions.
+--
+-- A name in a generated expression resolves against the table being defined unless a
+-- FROM clause inside the expression binds it — the same rule a CHECK constraint
+-- follows. The dependency analysis (extractGeneratedColumnDependencies) and the ALTER
+-- ADD COLUMN pre-flight (validateAddColumnGeneratedRefs) share one scope-aware
+-- collector (src/schema/generated-column-refs.ts), so a subquery's own FROM sources
+-- bind their columns and the owning table neither falsely rejects the name nor
+-- records a false dependency edge. Genuine typos and genuine cycles still raise the
+-- same errors as before.
+
+-- ===================================
+-- 1. Subquery over another table, inner name UNQUALIFIED — accepted, correct value.
+--    (Previously: "Column 'v' referenced by generated column 'g' not found in table 't'".)
+-- ===================================
+
+create table d (k integer primary key, v integer);
+insert into d values (1, 42);
+
+create table t (
+	id integer primary key,
+	g integer generated always as ((select v from d where d.k = id limit 1))
+);
+insert into t (id) values (1);
+
+select id, g from t;
+→ [{"id":1,"g":42}]
+
+drop table t;
+drop table d;
+
+-- ===================================
+-- 2. Two generated columns each reading ANOTHER table's like-named column —
+--    no false cycle, both values correct.
+-- ===================================
+
+create table d2 (k integer primary key, w integer, g integer);
+insert into d2 values (1, 10, 20);
+
+create table t2 (
+	id integer primary key,
+	w integer generated always as ((select g from d2 where d2.k = id limit 1)),
+	g integer generated always as ((select w from d2 where d2.k = id limit 1))
+);
+insert into t2 (id) values (1);
+
+select id, w, g from t2;
+→ [{"id":1,"w":20,"g":10}]
+
+drop table t2;
+drop table d2;
+
+-- ===================================
+-- 3. Generated column whose subquery selects another table's column with the SAME
+--    name as itself — no false self-cycle.
+-- ===================================
+
+create table l0 (k integer primary key, g integer);
+insert into l0 values (1, 7);
+
+create table l1 (
+	id integer primary key,
+	g integer generated always as ((select g from l0 where l0.k = id limit 1))
+);
+insert into l1 (id) values (1);
+
+select id, g from l1;
+→ [{"id":1,"g":7}]
+
+drop table l1;
+drop table l0;
+
+-- ===================================
+-- 4. Common table expression binds the inner name — accepted.
+-- ===================================
+
+create table j1 (
+	id integer primary key,
+	g integer generated always as ((with c(v) as (select 7) select v from c))
+);
+insert into j1 (id) values (1);
+
+select id, g from j1;
+→ [{"id":1,"g":7}]
+
+drop table j1;
+
+-- ===================================
+-- 5. Aliased self source: the alias binds the subquery's FROM, so the inner bare `a`
+--    is that source's column, not the row being computed. Nullable because the
+--    subquery finds no row while the table is still empty.
+-- ===================================
+
+create table s1 (
+	id integer primary key,
+	a integer,
+	g integer null generated always as ((select a from s1 x where x.id = 1 limit 1))
+);
+insert into s1 (id, a) values (1, 5);
+insert into s1 (id, a) values (2, 6);
+
+select id, g from s1 order by id;
+→ [{"id":1,"g":null},{"id":2,"g":5}]
+
+drop table s1;
+
+-- ===================================
+-- 6. A real table named "new": the FROM binding wins over the row-image reading
+--    (`new` is not a reserved word).
+-- ===================================
+
+create table "new" (a integer primary key);
+insert into "new" values (3);
+
+create table tn (
+	id integer primary key,
+	g integer generated always as ((select max("new".a) from "new"))
+);
+insert into tn (id) values (1);
+
+select id, g from tn;
+→ [{"id":1,"g":3}]
+
+drop table tn;
+drop table "new";
+
+-- ===================================
+-- 7. Subquery over the table's OWN pre-insert rows — the in-flight column set
+--    answers for the table before the catalog holds it. Nullable: the subquery
+--    sees no rows while inserting the first one.
+-- ===================================
+
+create table own1 (
+	id integer primary key,
+	g integer null generated always as ((select max(id) from own1))
+);
+insert into own1 (id) values (5);
+
+select id, g from own1;
+→ [{"id":5,"g":null}]
+
+drop table own1;
+
+-- ===================================
+-- 8. Dependency edges survive the scope awareness: an unrebound `new.<col>` and a
+--    schema-qualified self reference both bind the owning row, so DROP COLUMN of the
+--    referenced column is still refused.
+-- ===================================
+
+create table tnew (id integer primary key, a integer, g integer generated always as (new.a * 2));
+alter table tnew drop column a;
+-- error: Cannot drop column 'a' from 'tnew': it is referenced by generated column 'g'
+drop table tnew;
+
+create table sq3 (id integer primary key, a integer, g integer generated always as (main.sq3.a + 1));
+alter table sq3 drop column a;
+-- error: Cannot drop column 'a' from 'sq3': it is referenced by generated column 'g'
+drop table sq3;
+
+-- A qualifier naming ANOTHER schema is not a self reference even though the bare
+-- names collide — and nothing else binds it either, so CREATE TABLE rejects the
+-- declaration up front (see 41-generated-column-errors.sqllogic § 4).
+create table sqm (id integer primary key, a integer, g integer generated always as ("temp".sqm.a + 1));
+-- error: binds nothing
+
+-- ===================================
+-- 9. The name a subquery's FROM binds is a reference to THAT table, so the
+--    cross-table column guards see it: dropping the referenced column is refused,
+--    and renaming it rewrites the generated body (the value still computes).
+-- ===================================
+
+create table dref (k integer primary key, v integer);
+insert into dref values (1, 42);
+create table tref (id integer primary key, g integer generated always as ((select v from dref where dref.k = id limit 1)));
+
+alter table dref drop column v;
+-- error: Cannot drop column 'v' from 'dref': it is referenced by the GENERATED expression of column 'g' on table 'tref'
+
+alter table dref rename column v to v2;
+-- run
+
+insert into tref (id) values (1);
+select id, g from tref;
+→ [{"id":1,"g":42}]
+
+drop table tref;
+drop table dref;
+
+-- ===================================
+-- 10. An inner name that ALSO names a column of the table being defined belongs to
+--     the subquery's source — analysis and evaluation agree on that reading.
+-- ===================================
+
+create table dsh (k integer primary key, id integer);
+insert into dsh values (1, 99);
+
+create table tsh (id integer primary key);
+insert into tsh values (1);
+alter table tsh add column h integer generated always as ((select id from dsh where dsh.k = 1 limit 1));
+-- run
+
+insert into tsh (id) values (7);
+select id, h from tsh order by id;
+→ [{"id":1,"h":99},{"id":7,"h":99}]
+
+drop table tsh;
+drop table dsh;
+
+-- ===================================
+-- 11. Negative arms — genuine mistakes still raise the original messages.
+-- ===================================
+
+create table n1 (id integer primary key, g integer generated always as (nosuch + 1));
+-- error: Column 'nosuch' referenced by generated column 'g' not found in table 'n1'
+
+-- A typo INSIDE a subquery whose FROM does not expose the name is still a typo.
+create table dz (k integer primary key);
+create table nz (id integer primary key, g integer generated always as ((select nosuch from dz limit 1)));
+-- error: Column 'nosuch' referenced by generated column 'g' not found in table 'nz'
+drop table dz;
+
+create table n2 (id integer primary key);
+alter table n2 add column g integer generated always as (g + 1);
+-- error: Cyclic dependency in generated columns: 'g'
+drop table n2;
+
+create table n3 (
+	id integer primary key,
+	a integer generated always as (b + 1),
+	b integer generated always as (a + 1)
+);
+-- error: Cyclic dependency in generated columns
+
+-- An unrebound `new.` names the row being computed, so an unknown name behind it is a
+-- typo like any other. (Behavior change: this was accepted at DDL time before the
+-- scope-aware analysis and only failed at the first write.)
+create table n4 (id integer primary key, g integer generated always as (new.nosuch + 1));
+-- error: Column 'nosuch' referenced by generated column 'g' not found in table 'n4'
+
+-- ===================================
+-- 12. An unbound qualifier reached only through an OPAQUE frame (a derived
+--     table's body) is undecidable, not rejected. The walk cannot see what such
+--     a body binds, so it defers rather than refusing a declaration it cannot
+--     prove wrong — contrast 41-generated-column-errors.sqllogic § 4, where no
+--     opaque frame intervenes and CREATE TABLE rejects up front. Documented
+--     residual (see the NOTE in src/schema/generated-column-refs.ts): the
+--     declaration is accepted and the first write is what reports the name.
+-- ===================================
+
+create table dop (k integer primary key, v integer);
+
+create table sop (
+	id integer primary key,
+	a integer,
+	g integer generated always as ((select y from (select zz.v as y from dop) s limit 1))
+);
+
+drop table sop;
+drop table dop;
+
+-- ===================================
+-- 13. Each leg of a compound builds its OWN FROM scope: a bare name in the second
+--     leg is NOT captured by the first leg's sources. Here `cs_src` exposes a
+--     column named `b` and the second leg's source does not, so the second leg's
+--     bare `b` binds the row being computed — which means `g` depends on `b` and
+--     must be computed after it. `g` is declared FIRST, so declaration order alone
+--     would compute it while `b` is still null; only the recorded dependency edge
+--     gets the right value. (Before the compound legs were split out of the
+--     leading leg's frame, `b` read as `cs_src`'s column, no edge was recorded,
+--     `g` computed against `b`'s NULL placeholder, and the insert failed
+--     `NOT NULL constraint failed: cs.g` — verified by reverting the split.)
+-- ===================================
+
+create table cs_src (k integer primary key, b integer);
+insert into cs_src values (1, 999);
+
+create table cs_probe (k integer primary key);
+insert into cs_probe values (1);
+
+create table cs (
+	id integer primary key,
+	g integer generated always as ((select b from cs_src where 1 = 0 union all select b from cs_probe where k = 1)),
+	b integer generated always as (id * 10)
+);
+insert into cs (id) values (7);
+
+select id, g, b from cs;
+→ [{"id":7,"g":70,"b":70}]
+
+drop table cs;
+drop table cs_probe;
+drop table cs_src;
+
+-- ===================================
+-- 14. View write-through metadata inside a generated body records NO dependency
+--     edge. `with inverse (…)` on a result column and a trailing `with defaults (…)`
+--     are evaluated against the row written THROUGH A VIEW — an inverse expression
+--     may only name that select's OWN output columns as `new.<column>` — so nothing
+--     in them can name the row being computed here, and in a read-only generated
+--     body they are never evaluated at all. Both bodies below spell a name that is
+--     ALSO the generated column being defined; classifying a sealed reference as
+--     undecidable instead would record a self-edge and raise a false
+--     `Cyclic dependency in generated columns: 'g'`.
+-- ===================================
+
+create table gi_src (k integer primary key, x integer);
+insert into gi_src values (1, 5);
+
+create table gi (
+	id integer primary key,
+	g integer generated always as ((select x as g with inverse (x = new.g) from gi_src limit 1))
+);
+insert into gi (id) values (2);
+
+select id, g from gi;
+→ [{"id":2,"g":5}]
+
+create table gd (
+	id integer primary key,
+	g integer generated always as ((select x from gi_src limit 1 with defaults (x = g)))
+);
+insert into gd (id) values (3);
+
+select id, g from gd;
+→ [{"id":3,"g":5}]
+
+drop table gd;
+drop table gi;
+drop table gi_src;

package/test/logic/41-generated-columns.sqllogic

@@ -0,0 +1,361 @@
+-- generated-columns.sqllogic - Testing GENERATED ALWAYS AS computed columns
+
+-- === STORED Generated Columns ===
+
+-- Basic STORED generated column (use integers to avoid floating point)
+CREATE TABLE t_gen_stored (
+    id INTEGER PRIMARY KEY,
+    base_price INTEGER NOT NULL,
+    multiplier INTEGER NOT NULL DEFAULT 2,
+    total_price INTEGER GENERATED ALWAYS AS (base_price * multiplier) STORED
+);
+
+-- INSERT with generated column computed automatically (named columns)
+INSERT INTO t_gen_stored (id, base_price, multiplier) VALUES (1, 100, 3);
+SELECT id, base_price, multiplier, total_price FROM t_gen_stored WHERE id = 1;
+→ [{"id":1,"base_price":100,"multiplier":3,"total_price":300}]
+
+-- INSERT with default multiplier
+INSERT INTO t_gen_stored (id, base_price) VALUES (2, 200);
+SELECT id, total_price FROM t_gen_stored WHERE id = 2;
+→ [{"id":2,"total_price":400}]
+
+-- UPDATE triggers recomputation of stored generated column
+UPDATE t_gen_stored SET base_price = 50 WHERE id = 1;
+SELECT id, base_price, total_price FROM t_gen_stored WHERE id = 1;
+→ [{"id":1,"base_price":50,"total_price":150}]
+
+-- UPDATE multiplier also triggers recomputation
+UPDATE t_gen_stored SET multiplier = 5 WHERE id = 1;
+SELECT id, total_price FROM t_gen_stored WHERE id = 1;
+→ [{"id":1,"total_price":250}]
+
+-- Cannot INSERT into generated column (explicit column list)
+INSERT INTO t_gen_stored (id, base_price, multiplier, total_price) VALUES (3, 100, 2, 999);
+-- error: Cannot INSERT into generated column 'total_price'
+
+-- Cannot UPDATE a generated column
+UPDATE t_gen_stored SET total_price = 999 WHERE id = 1;
+-- error: Cannot UPDATE generated column 'total_price'
+
+-- SELECT * includes generated columns
+SELECT * FROM t_gen_stored WHERE id = 2;
+→ [{"id":2,"base_price":200,"multiplier":2,"total_price":400}]
+
+DROP TABLE t_gen_stored;
+
+-- === STORED generated column with string concatenation ===
+
+CREATE TABLE t_gen_concat (
+    id INTEGER PRIMARY KEY,
+    first_name TEXT NOT NULL,
+    last_name TEXT NOT NULL,
+    full_name TEXT GENERATED ALWAYS AS (first_name || ' ' || last_name) STORED
+);
+
+INSERT INTO t_gen_concat (id, first_name, last_name) VALUES (1, 'John', 'Doe');
+SELECT full_name FROM t_gen_concat WHERE id = 1;
+→ [{"full_name":"John Doe"}]
+
+UPDATE t_gen_concat SET first_name = 'Jane' WHERE id = 1;
+SELECT full_name FROM t_gen_concat WHERE id = 1;
+→ [{"full_name":"Jane Doe"}]
+
+DROP TABLE t_gen_concat;
+
+-- === Interaction with NOT NULL ===
+
+CREATE TABLE t_gen_notnull (
+    id INTEGER PRIMARY KEY,
+    a INTEGER NULL,
+    b INTEGER GENERATED ALWAYS AS (a * 2) STORED NOT NULL
+);
+
+-- NULL input causes generated column to be NULL, violating NOT NULL
+INSERT INTO t_gen_notnull (id, a) VALUES (1, NULL);
+-- error: NOT NULL constraint failed: t_gen_notnull.b
+
+-- Non-null input succeeds
+INSERT INTO t_gen_notnull (id, a) VALUES (1, 5);
+SELECT b FROM t_gen_notnull WHERE id = 1;
+→ [{"b":10}]
+
+DROP TABLE t_gen_notnull;
+
+-- === Interaction with CHECK constraints ===
+
+CREATE TABLE t_gen_check (
+    id INTEGER PRIMARY KEY,
+    price INTEGER NOT NULL,
+    discount INTEGER NOT NULL DEFAULT 0,
+    final_price INTEGER GENERATED ALWAYS AS (price - discount) STORED,
+    CHECK (final_price >= 0)
+);
+
+-- Valid: final_price = 100 - 10 = 90
+INSERT INTO t_gen_check (id, price, discount) VALUES (1, 100, 10);
+SELECT final_price FROM t_gen_check WHERE id = 1;
+→ [{"final_price":90}]
+
+-- Invalid: final_price = 50 - 100 = -50 violates CHECK
+INSERT INTO t_gen_check (id, price, discount) VALUES (2, 50, 100);
+-- error: CHECK constraint failed
+
+DROP TABLE t_gen_check;
+
+-- === Cannot have both DEFAULT and GENERATED ===
+
+CREATE TABLE t_gen_default_err (
+    id INTEGER PRIMARY KEY,
+    a INTEGER DEFAULT 5 GENERATED ALWAYS AS (id * 2) STORED
+);
+-- error: cannot have both DEFAULT and GENERATED
+
+-- === Multiple generated columns ===
+
+CREATE TABLE t_gen_multi (
+    id INTEGER PRIMARY KEY,
+    a INTEGER NOT NULL,
+    b INTEGER NOT NULL,
+    sum_ab INTEGER GENERATED ALWAYS AS (a + b) STORED,
+    diff_ab INTEGER GENERATED ALWAYS AS (a - b) STORED
+);
+
+INSERT INTO t_gen_multi (id, a, b) VALUES (1, 10, 3);
+SELECT sum_ab, diff_ab FROM t_gen_multi WHERE id = 1;
+→ [{"sum_ab":13,"diff_ab":7}]
+
+UPDATE t_gen_multi SET a = 20 WHERE id = 1;
+SELECT sum_ab, diff_ab FROM t_gen_multi WHERE id = 1;
+→ [{"sum_ab":23,"diff_ab":17}]
+
+DROP TABLE t_gen_multi;
+
+-- === RETURNING with generated columns ===
+
+CREATE TABLE t_gen_returning (
+    id INTEGER PRIMARY KEY,
+    x INTEGER NOT NULL,
+    y INTEGER GENERATED ALWAYS AS (x * x) STORED
+);
+
+INSERT INTO t_gen_returning (id, x) VALUES (1, 5) RETURNING id, x, y;
+→ [{"id":1,"x":5,"y":25}]
+
+UPDATE t_gen_returning SET x = 7 WHERE id = 1 RETURNING id, y;
+→ [{"id":1,"y":49}]
+
+DROP TABLE t_gen_returning;
+
+-- === VIRTUAL Generated Columns ===
+-- Note: VIRTUAL columns currently behave like STORED (storage optimization deferred).
+-- The semantic behavior is correct: cannot INSERT/UPDATE, expression is evaluated.
+
+CREATE TABLE t_gen_virtual (
+    id INTEGER PRIMARY KEY,
+    width INTEGER NOT NULL,
+    height INTEGER NOT NULL,
+    area INTEGER GENERATED ALWAYS AS (width * height) VIRTUAL
+);
+
+-- INSERT computes the virtual column
+INSERT INTO t_gen_virtual (id, width, height) VALUES (1, 5, 10);
+SELECT id, width, height, area FROM t_gen_virtual WHERE id = 1;
+→ [{"id":1,"width":5,"height":10,"area":50}]
+
+-- Cannot INSERT into virtual column
+INSERT INTO t_gen_virtual (id, width, height, area) VALUES (2, 3, 4, 99);
+-- error: Cannot INSERT into generated column 'area'
+
+-- Cannot UPDATE virtual column
+UPDATE t_gen_virtual SET area = 100 WHERE id = 1;
+-- error: Cannot UPDATE generated column 'area'
+
+-- UPDATE recalculates virtual column
+UPDATE t_gen_virtual SET width = 8 WHERE id = 1;
+SELECT area FROM t_gen_virtual WHERE id = 1;
+→ [{"area":80}]
+
+-- Default VIRTUAL (no STORED/VIRTUAL keyword defaults to VIRTUAL per SQL standard)
+CREATE TABLE t_gen_default_mode (
+    id INTEGER PRIMARY KEY,
+    x INTEGER NOT NULL,
+    doubled INTEGER GENERATED ALWAYS AS (x * 2)
+);
+
+INSERT INTO t_gen_default_mode (id, x) VALUES (1, 7);
+SELECT doubled FROM t_gen_default_mode WHERE id = 1;
+→ [{"doubled":14}]
+
+DROP TABLE t_gen_default_mode;
+DROP TABLE t_gen_virtual;
+
+-- ============================================================
+-- === Row-scope spellings: one meaning at every write site ===
+--
+-- A `generated always as (...)` body is compiled by four different statements —
+-- the INSERT row expansion, the `on conflict do update` recompute, the UPDATE
+-- recompute, and the `alter table ... add column` backfill. All four go through
+-- one builder (`planner/building/generated-column-scope.ts`), so a declaration
+-- the engine accepts is one every subsequent write accepts.
+--
+-- Accepted: bare `col`, `table.col`, `schema.table.col`, `new.col`.
+-- Rejected: `old.col` (see 41-generated-column-errors.sqllogic) and any other
+-- qualifier. The ALTER arms live in
+-- 41.13-alter-add-column-generated-backfill.sqllogic.
+-- ============================================================
+
+-- --- bare `col` ---
+
+create table t_spell_bare (id integer primary key, a integer,
+	g integer generated always as (a * 2) stored);
+insert into t_spell_bare (id, a) values (1, 1);
+select id, a, g from t_spell_bare order by id;
+→ [{"id":1,"a":1,"g":2}]
+
+update t_spell_bare set a = 5 where id = 1;
+select id, a, g from t_spell_bare order by id;
+→ [{"id":1,"a":5,"g":10}]
+
+insert into t_spell_bare (id, a) values (1, 9) on conflict (id) do update set a = 9;
+select id, a, g from t_spell_bare order by id;
+→ [{"id":1,"a":9,"g":18}]
+
+drop table t_spell_bare;
+
+-- --- `table.col` — the body qualifies its own table ---
+
+create table t_spell_tbl (id integer primary key, a integer,
+	g integer generated always as (t_spell_tbl.a * 2) stored);
+insert into t_spell_tbl (id, a) values (1, 1);
+select id, a, g from t_spell_tbl order by id;
+→ [{"id":1,"a":1,"g":2}]
+
+update t_spell_tbl set a = 5 where id = 1;
+select id, a, g from t_spell_tbl order by id;
+→ [{"id":1,"a":5,"g":10}]
+
+insert into t_spell_tbl (id, a) values (1, 9) on conflict (id) do update set a = 9;
+select id, a, g from t_spell_tbl order by id;
+→ [{"id":1,"a":9,"g":18}]
+
+drop table t_spell_tbl;
+
+-- --- `schema.table.col` — the body qualifies its own schema and table ---
+
+create table t_spell_sch (id integer primary key, a integer,
+	g integer generated always as (main.t_spell_sch.a * 2) stored);
+insert into t_spell_sch (id, a) values (1, 1);
+select id, a, g from t_spell_sch order by id;
+→ [{"id":1,"a":1,"g":2}]
+
+update t_spell_sch set a = 5 where id = 1;
+select id, a, g from t_spell_sch order by id;
+→ [{"id":1,"a":5,"g":10}]
+
+insert into t_spell_sch (id, a) values (1, 9) on conflict (id) do update set a = 9;
+select id, a, g from t_spell_sch order by id;
+→ [{"id":1,"a":9,"g":18}]
+
+drop table t_spell_sch;
+
+-- --- `new.col` — an exact alias for the bare form ---
+
+create table t_spell_new (id integer primary key, a integer,
+	g integer generated always as (new.a * 2) stored);
+insert into t_spell_new (id, a) values (1, 1);
+select id, a, g from t_spell_new order by id;
+→ [{"id":1,"a":1,"g":2}]
+
+update t_spell_new set a = 5 where id = 1;
+select id, a, g from t_spell_new order by id;
+→ [{"id":1,"a":5,"g":10}]
+
+insert into t_spell_new (id, a) values (1, 9) on conflict (id) do update set a = 9;
+select id, a, g from t_spell_new order by id;
+→ [{"id":1,"a":9,"g":18}]
+
+drop table t_spell_new;
+
+-- --- `new.<other generated column>` sees the freshly computed value ---
+-- The generated columns are computed in dependency order, so g2 reads g1's new
+-- value, not the NULL placeholder the row expansion starts from.
+
+create table t_spell_chain (id integer primary key, a integer,
+	g1 integer generated always as (a * 2) stored,
+	g2 integer generated always as (new.g1 + 1) stored);
+insert into t_spell_chain (id, a) values (1, 5);
+select id, a, g1, g2 from t_spell_chain order by id;
+→ [{"id":1,"a":5,"g1":10,"g2":11}]
+
+update t_spell_chain set a = 10 where id = 1;
+select id, a, g1, g2 from t_spell_chain order by id;
+→ [{"id":1,"a":10,"g1":20,"g2":21}]
+
+insert into t_spell_chain (id, a) values (1, 3) on conflict (id) do update set a = 3;
+select id, a, g1, g2 from t_spell_chain order by id;
+→ [{"id":1,"a":3,"g1":6,"g2":7}]
+
+drop table t_spell_chain;
+
+-- --- a real table named `new` is still reachable from a generated body ---
+-- `new` is not a reserved word. The row scope is an ANCESTOR of every subquery
+-- planned inside the body, so the subquery's own FROM binds the name first and
+-- `"new".a` reads the table, not the row being written.
+
+create table "new" (a integer primary key);
+insert into "new" values (7);
+
+create table t_spell_newtbl (id integer primary key,
+	g integer generated always as ((select max("new".a) from "new")) stored);
+insert into t_spell_newtbl (id) values (1);
+select id, g from t_spell_newtbl order by id;
+→ [{"id":1,"g":7}]
+
+drop table t_spell_newtbl;
+drop table "new";
+
+-- --- a mutation-context variable does NOT shadow a column here ---
+-- In a CHECK or a column DEFAULT a `with context` variable claims the bare name.
+-- A generated body is different on purpose: its value is a pure function of the
+-- row being written and must compute identically at all four sites, and the
+-- `alter table ... add column` backfill has no context envelope to read. So the
+-- bare name always means the column. `g` below is a + 1 = 4, NOT ctx + 1 = 101.
+
+create table t_spell_ctx (id integer primary key, a integer,
+	g integer generated always as (a + 1) stored) with context (a integer);
+insert into t_spell_ctx (id, a) values (1, 3) with context a = 100;
+select id, a, g from t_spell_ctx order by id;
+→ [{"id":1,"a":3,"g":4}]
+
+drop table t_spell_ctx;
+
+-- --- the row's columns resolve at their DECLARED type, so a declared COLLATE
+-- --- applies inside the body — identically at all three write sites ---
+-- The shared builder resolves each column reference against
+-- `columnSchemaToScalarType(column)`, which carries the column's declared
+-- collation, rather than against the type of whatever expression produced the
+-- row attribute. A `collate nocase` column therefore compares case-insensitively
+-- inside a generated body, the same way it does in a CHECK and on the read path.
+
+create table t_spell_coll (id integer primary key, a text collate nocase,
+	g integer generated always as (case when a = 'ABC' then 1 else 0 end) stored);
+
+insert into t_spell_coll (id, a) values (1, 'abc');
+select id, a, g from t_spell_coll order by id;
+→ [{"id":1,"a":"abc","g":1}]
+
+update t_spell_coll set a = 'AbC' where id = 1;
+select id, g from t_spell_coll order by id;
+→ [{"id":1,"g":1}]
+
+insert into t_spell_coll (id, a) values (1, 'zzz') on conflict (id) do update set a = 'ABc';
+select id, g from t_spell_coll order by id;
+→ [{"id":1,"g":1}]
+
+-- a value the collation does NOT equate still yields 0, so the arm is not vacuous
+update t_spell_coll set a = 'abd' where id = 1;
+select id, g from t_spell_coll order by id;
+→ [{"id":1,"g":0}]
+
+drop table t_spell_coll;