@quereus/quereus 4.20.1 → 4.20.2

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

@@ -0,0 +1,598 @@
+-- adapted from SQLite test/gencol1.test
+-- Generated-column scenarios beyond 41-generated-columns.sqllogic.
+
+-- ===================================
+-- 1. Chain — generated column referencing another generated column
+-- ===================================
+
+create table t_chain (
+	id integer primary key,
+	a integer not null,
+	m integer generated always as (a * 2) stored,
+	w integer generated always as (m * 5) stored
+);
+
+insert into t_chain (id, a) values (1, 3);
+
+select a, m, w from t_chain where id = 1;
+→ [{"a":3,"m":6,"w":30}]
+
+update t_chain set a = 4 where id = 1;
+
+select a, m, w from t_chain where id = 1;
+→ [{"a":4,"m":8,"w":40}]
+
+drop table t_chain;
+
+-- ===================================
+-- 1b. Reverse-declaration-order chain — `w` declared before its dependency `m`
+-- ===================================
+
+create table t_chain_rev (
+	id integer primary key,
+	a integer not null,
+	w integer generated always as (m * 5) stored,
+	m integer generated always as (a * 2) stored
+);
+
+insert into t_chain_rev (id, a) values (1, 3);
+
+select a, m, w from t_chain_rev where id = 1;
+→ [{"a":3,"m":6,"w":30}]
+
+update t_chain_rev set a = 4 where id = 1;
+
+select a, m, w from t_chain_rev where id = 1;
+→ [{"a":4,"m":8,"w":40}]
+
+drop table t_chain_rev;
+
+-- ===================================
+-- 2. Generated column used in WHERE / ORDER BY / GROUP BY
+-- ===================================
+
+create table t_q (
+	id integer primary key,
+	a integer not null,
+	b integer not null,
+	s integer generated always as (a + b) stored
+);
+
+insert into t_q (id, a, b) values (1, 1, 2), (2, 3, 1), (3, 2, 2);
+
+-- WHERE on generated column
+select id from t_q where s = 4 order by id;
+→ [{"id":2},{"id":3}]
+
+-- GROUP BY on generated column
+select s, count(*) as n from t_q group by s order by s;
+→ [{"s":3,"n":1},{"s":4,"n":2}]
+
+-- ORDER BY on generated column
+select id, s from t_q order by s desc, id;
+→ [{"id":2,"s":4},{"id":3,"s":4},{"id":1,"s":3}]
+
+drop table t_q;
+
+-- ===================================
+-- 3. Type coercion via generated column
+-- ===================================
+
+create table t_typed (
+	id integer primary key,
+	c any null,
+	t text generated always as (typeof(c)) stored
+);
+
+insert into t_typed (id, c) values (1, 5), (2, 'abc'), (3, 5.5), (4, null);
+
+select id, t from t_typed order by id;
+→ [{"id":1,"t":"integer"},{"id":2,"t":"text"},{"id":3,"t":"real"},{"id":4,"t":"null"}]
+
+drop table t_typed;
+
+-- ===================================
+-- 4. Generated column with UNIQUE constraint
+-- ===================================
+
+create table t_u (
+	id integer primary key,
+	a integer not null,
+	b integer generated always as (a * 10) stored unique
+);
+
+insert into t_u (id, a) values (1, 1), (2, 2);
+
+-- duplicate generated value should violate UNIQUE
+insert into t_u (id, a) values (3, 1);
+-- error: UNIQUE
+
+drop table t_u;
+
+-- ===================================
+-- 5. Generated column as PRIMARY KEY
+-- ===================================
+
+create table t_pk (
+	a integer not null,
+	k integer generated always as (a + 100) stored primary key
+);
+
+insert into t_pk (a) values (1);
+
+-- duplicate generated PK value should fail
+insert into t_pk (a) values (1);
+-- error:
+
+select k from t_pk;
+→ [{"k":101}]
+
+drop table t_pk;
+
+-- ===================================
+-- 6. Generated column whose expression is a scalar subquery
+--    (deterministic within a statement, but the evaluator resolves ASYNCHRONOUSLY —
+--     UPDATE's generated-column recompute must await it, not store the Promise)
+-- ===================================
+
+create table t_src (k integer primary key);
+
+insert into t_src values (1), (2), (3);
+
+create table t_sub (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as ((select count(*) from t_src))
+);
+
+insert into t_sub (id, w) values (1, 1), (2, 2);
+
+select id, w, g from t_sub order by id;
+→ [{"id":1,"w":1,"g":3},{"id":2,"w":2,"g":3}]
+
+-- updating an unrelated column re-runs the generated expression
+update t_sub set w = 5 where id = 1;
+
+select id, w, g from t_sub order by id;
+→ [{"id":1,"w":5,"g":3},{"id":2,"w":2,"g":3}]
+
+-- the subquery's source changes: a later update must recompute, not carry the old value
+insert into t_src values (4), (5);
+
+update t_sub set w = 6 where id = 1;
+
+select id, w, g from t_sub order by id;
+→ [{"id":1,"w":6,"g":5},{"id":2,"w":2,"g":3}]
+
+-- multi-row update (no WHERE) — exercises phase-2 context teardown across iterations
+update t_sub set w = w + 10;
+
+select id, w, g from t_sub order by id;
+→ [{"id":1,"w":16,"g":5},{"id":2,"w":12,"g":5}]
+
+drop table t_sub;
+drop table t_src;
+
+-- ===================================
+-- 7. Chain across the async path — a generated column feeding another
+-- ===================================
+
+create table t_src2 (k integer primary key);
+
+insert into t_src2 values (1), (2);
+
+create table t_sub_chain (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as ((select count(*) from t_src2)) stored,
+	g2 integer generated always as (g * 2) stored
+);
+
+insert into t_sub_chain (id, w) values (1, 1);
+
+select w, g, g2 from t_sub_chain;
+→ [{"w":1,"g":2,"g2":4}]
+
+insert into t_src2 values (3);
+
+update t_sub_chain set w = 9 where id = 1;
+
+select w, g, g2 from t_sub_chain;
+→ [{"w":9,"g":3,"g2":6}]
+
+drop table t_sub_chain;
+drop table t_src2;
+
+-- ===================================
+-- 8. Correlated subquery generated column, multi-row UPDATE
+--    Sections 6 and 7 use an UNCORRELATED subquery, which never reads the row
+--    context UPDATE installs for its phase-2 recompute. This one does — the
+--    subquery's `id` resolves against the row being updated — across several
+--    rows in one statement, so the phase-2 context must be installed and torn
+--    down correctly on every iteration, not just the first.
+--    Note the other table's column is qualified (`t_src3.k`): an unqualified
+--    name inside a generated expression is read as a reference to THIS table
+--    and rejected at create time (see docs/sql-alter.md § ADD COLUMN).
+-- ===================================
+
+create table t_src3 (k integer primary key);
+
+insert into t_src3 values (1), (2), (3);
+
+create table t_corr (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as ((select count(*) from t_src3 where t_src3.k <= id))
+);
+
+insert into t_corr (id, w) values (1, 10), (2, 20), (3, 30);
+
+select id, w, g from t_corr order by id;
+→ [{"id":1,"w":10,"g":1},{"id":2,"w":20,"g":2},{"id":3,"w":30,"g":3}]
+
+update t_corr set w = w + 1;
+
+select id, w, g from t_corr order by id;
+→ [{"id":1,"w":11,"g":1},{"id":2,"w":21,"g":2},{"id":3,"w":31,"g":3}]
+
+drop table t_corr;
+drop table t_src3;
+
+-- ===================================
+-- 9. `on conflict … do update` recomputes generated columns
+--    The DO UPDATE arm composes its row from the EXISTING row plus the SET
+--    assignments and writes it directly, so it needs its own second-pass
+--    recompute — the INSERT-side and UPDATE-side ones never run for it.
+-- ===================================
+
+create table t_up (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as (w * 2) stored
+);
+
+insert into t_up (id, w) values (1, 1);
+
+select id, w, g from t_up;
+→ [{"id":1,"w":1,"g":2}]
+
+-- literal assignment: g derives from the POST-update w, not the old one
+insert into t_up (id, w) values (1, 7) on conflict (id) do update set w = 7;
+
+select id, w, g from t_up;
+→ [{"id":1,"w":7,"g":14}]
+
+-- `excluded.` assignment (the proposed insert value)
+insert into t_up (id, w) values (1, 20) on conflict (id) do update set w = excluded.w;
+
+select id, w, g from t_up;
+→ [{"id":1,"w":20,"g":40}]
+
+-- assignment reading the EXISTING row (unqualified `w` = 20)
+insert into t_up (id, w) values (1, 0) on conflict (id) do update set w = w + 1;
+
+select id, w, g from t_up;
+→ [{"id":1,"w":21,"g":42}]
+
+-- assigning a generated column is rejected, exactly as `update t_up set g = 99` is
+insert into t_up (id, w) values (1, 5) on conflict (id) do update set g = 99;
+-- error: Cannot UPDATE generated column 'g'
+
+-- rejected at plan time, so nothing was written
+select id, w, g from t_up;
+→ [{"id":1,"w":21,"g":42}]
+
+-- `on conflict … do nothing` writes nothing at all (control)
+insert into t_up (id, w) values (1, 99) on conflict (id) do nothing;
+
+select id, w, g from t_up;
+→ [{"id":1,"w":21,"g":42}]
+
+drop table t_up;
+
+-- ===================================
+-- 9b. DO UPDATE across a generated-from-generated chain, declared in reverse
+--     dependency order — the second pass must follow topological order, not
+--     declaration order.
+-- ===================================
+
+create table t_up_chain (
+	id integer primary key,
+	a  integer,
+	w  integer generated always as (m * 5) stored,
+	m  integer generated always as (a * 2) stored
+);
+
+insert into t_up_chain (id, a) values (1, 3);
+
+select a, m, w from t_up_chain;
+→ [{"a":3,"m":6,"w":30}]
+
+insert into t_up_chain (id, a) values (1, 4) on conflict (id) do update set a = excluded.a;
+
+select a, m, w from t_up_chain;
+→ [{"a":4,"m":8,"w":40}]
+
+drop table t_up_chain;
+
+-- ===================================
+-- 9c. DO UPDATE with a subquery-valued generated column
+--     Its evaluator resolves ASYNCHRONOUSLY, so the second pass must await it
+--     rather than store the Promise. The source table changes between the two
+--     statements, so a carried-over value is visible in the result.
+-- ===================================
+
+create table t_up_src (k integer primary key);
+
+insert into t_up_src values (1), (2), (3);
+
+create table t_up_sub (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as ((select count(*) from t_up_src))
+);
+
+insert into t_up_sub (id, w) values (1, 1);
+
+select id, w, g from t_up_sub;
+→ [{"id":1,"w":1,"g":3}]
+
+insert into t_up_src values (4), (5);
+
+insert into t_up_sub (id, w) values (1, 2) on conflict (id) do update set w = excluded.w;
+
+select id, w, g from t_up_sub;
+→ [{"id":1,"w":2,"g":5}]
+
+drop table t_up_sub;
+drop table t_up_src;
+
+-- ===================================
+-- 9d. DO UPDATE with a CORRELATED subquery generated column whose correlation
+--     is on a column the SET clause changes — the second pass must bind the
+--     post-assignment row, not the pre-update existing row.
+-- ===================================
+
+create table t_up_corr_src (k integer primary key);
+
+insert into t_up_corr_src values (1), (2), (3), (4);
+
+create table t_up_corr (
+	id integer primary key,
+	w  integer,
+	c  integer generated always as ((select count(*) from t_up_corr_src where t_up_corr_src.k <= w))
+);
+
+insert into t_up_corr (id, w) values (1, 1);
+
+select id, w, c from t_up_corr;
+→ [{"id":1,"w":1,"c":1}]
+
+insert into t_up_corr (id, w) values (1, 3) on conflict (id) do update set w = excluded.w;
+
+select id, w, c from t_up_corr;
+→ [{"id":1,"w":3,"c":3}]
+
+drop table t_up_corr;
+drop table t_up_corr_src;
+
+-- ===================================
+-- 9e. Control — `insert or replace` (delete-then-insert) routes through the
+--     INSERT path, which already recomputes. Pinned so a future change to the
+--     upsert path cannot quietly regress it.
+-- ===================================
+
+create table t_rep (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as (w * 2) stored
+);
+
+insert into t_rep (id, w) values (1, 1);
+
+select id, w, g from t_rep;
+→ [{"id":1,"w":1,"g":2}]
+
+insert or replace into t_rep (id, w) values (1, 9);
+
+select id, w, g from t_rep;
+→ [{"id":1,"w":9,"g":18}]
+
+drop table t_rep;
+
+-- ===================================
+-- 9f. Generated column that IS the primary key, relocated by the recompute.
+--     The DO UPDATE arm issues its write with `oldKeyValues` taken from the
+--     existing row, so the row must MOVE to the new key rather than duplicate
+--     or be lost.
+-- ===================================
+
+create table t_pk_up (
+	a integer not null,
+	k integer generated always as (a + 100) stored primary key
+);
+
+insert into t_pk_up (a) values (1);
+
+select a, k from t_pk_up;
+→ [{"a":1,"k":101}]
+
+insert into t_pk_up (a) values (1) on conflict (k) do update set a = 2;
+
+select a, k from t_pk_up order by k;
+→ [{"a":2,"k":102}]
+
+drop table t_pk_up;
+
+-- ===================================
+-- 9g. RETURNING on the DO UPDATE arm reports the RECOMPUTED generated value.
+--     The arm builds its returned row from the stored image, so a recompute the
+--     second pass missed would surface here as the stale value.
+-- ===================================
+
+create table t_up_ret (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as (w * 2) stored
+);
+
+insert into t_up_ret (id, w) values (1, 1);
+
+insert into t_up_ret (id, w) values (1, 7) on conflict (id) do update set w = excluded.w returning id, w, g;
+→ [{"id":1,"w":7,"g":14}]
+
+drop table t_up_ret;
+
+-- ===================================
+-- 9h. A DO UPDATE clause whose WHERE excludes the row writes nothing — the
+--     recompute must not leak a value past the skipped write.
+-- ===================================
+
+create table t_up_where (
+	id integer primary key,
+	w  integer,
+	g  integer generated always as (w * 2) stored
+);
+
+insert into t_up_where (id, w) values (1, 1);
+
+insert into t_up_where (id, w) values (1, 7) on conflict (id) do update set w = excluded.w where w > 100;
+
+select id, w, g from t_up_where;
+→ [{"id":1,"w":1,"g":2}]
+
+insert into t_up_where (id, w) values (1, 7) on conflict (id) do update set w = excluded.w where w < 100;
+
+select id, w, g from t_up_where;
+→ [{"id":1,"w":7,"g":14}]
+
+drop table t_up_where;
+
+-- ===================================
+-- 9i. TWO `on conflict` clauses on one generated-column table. The emit-side
+--     split between user assignments and recomputes is built per clause, so each
+--     clause needs its own working second pass.
+-- ===================================
+
+create table t_up_multi (
+	id integer primary key,
+	u  integer unique,
+	w  integer,
+	g  integer generated always as (w * 2) stored
+);
+
+insert into t_up_multi (id, u, w) values (1, 10, 1);
+
+select id, u, w, g from t_up_multi;
+→ [{"id":1,"u":10,"w":1,"g":2}]
+
+-- conflicts on the PK -> first clause
+insert into t_up_multi (id, u, w) values (1, 99, 3) on conflict (id) do update set w = 3 on conflict (u) do update set w = 4;
+
+select id, u, w, g from t_up_multi;
+→ [{"id":1,"u":10,"w":3,"g":6}]
+
+-- conflicts on the unique column only -> second clause
+insert into t_up_multi (id, u, w) values (2, 10, 5) on conflict (id) do update set w = 3 on conflict (u) do update set w = 4;
+
+select id, u, w, g from t_up_multi;
+→ [{"id":1,"u":10,"w":4,"g":8}]
+
+drop table t_up_multi;
+
+-- ===================================
+-- 9j. MULTI-ROW DO UPDATE. Every other case here conflicts on one row; the
+--     second pass composes its row per conflicting row, so a statement mixing
+--     conflicting and non-conflicting rows must recompute each independently.
+-- ===================================
+
+create table t_up_many (id integer primary key, w integer, g integer generated always as (w * 2) stored);
+
+insert into t_up_many (id, w) values (1, 1), (2, 2);
+
+insert into t_up_many (id, w) values (1, 10), (2, 20), (3, 30) on conflict (id) do update set w = excluded.w;
+
+select id, w, g from t_up_many order by id;
+→ [{"id":1,"w":10,"g":20},{"id":2,"w":20,"g":40},{"id":3,"w":30,"g":60}]
+
+drop table t_up_many;
+
+-- ===================================
+-- 9k. A generated value whose expression type differs from the DECLARED column
+--     type is converted on the DO UPDATE arm too — it lands in the same cell as
+--     a user assignment, so it takes the same static-type coercion.
+-- ===================================
+
+create table t_up_coerce (
+	id integer primary key,
+	w  integer,
+	g  text generated always as (w * 2) stored
+);
+
+insert into t_up_coerce (id, w) values (1, 1);
+
+select id, w, g, typeof(g) as t from t_up_coerce;
+→ [{"id":1,"w":1,"g":"2","t":"text"}]
+
+insert into t_up_coerce (id, w) values (1, 5) on conflict (id) do update set w = excluded.w;
+
+select id, w, g, typeof(g) as t from t_up_coerce;
+→ [{"id":1,"w":5,"g":"10","t":"text"}]
+
+drop table t_up_coerce;
+
+-- ===================================
+-- 9l. A generated column whose dependency the SET clause does NOT touch keeps
+--     its value — the recompute reads the composed row, not the proposed insert.
+--     (`a` is 9 in the proposed row and 1 in the existing one; `g` must stay 10.)
+-- ===================================
+
+create table t_up_dep (id integer primary key, a integer, b integer, g integer generated always as (a * 10) stored);
+
+insert into t_up_dep (id, a, b) values (1, 1, 1);
+
+insert into t_up_dep (id, a, b) values (1, 9, 7) on conflict (id) do update set b = excluded.b;
+
+select id, a, b, g from t_up_dep;
+→ [{"id":1,"a":1,"b":7,"g":10}]
+
+drop table t_up_dep;
+
+-- ===================================
+-- 9m. Writing through a view whose basis table has a generated column. The
+--     view-mutation decomposition re-plans some writes as synthesized
+--     `on conflict … do update` statements, so the rejection above could in
+--     principle fire on a lowered statement. It cannot: the view-write
+--     classifier marks a projected generated column read-only and rejects
+--     first, with its own diagnostic. Pinned so that ordering does not drift.
+--     Writing the ORDINARY basis column through the same view still updates the
+--     generated one (that write lowers to a plain member UPDATE, whose own
+--     recompute covers it).
+-- ===================================
+
+create table gojp (pp integer primary key, base integer null, pv integer generated always as (base * 2) stored);
+
+create table gojc (cc integer primary key, pr integer null, cv integer null);
+
+create view gojv as select c.cc as cc, c.cv as cv, p.pv as pv, p.base as base from gojc c left join gojp p on p.pp = c.pr;
+
+insert into gojp (pp, base) values (1, 10);
+insert into gojc values (1, 1, 100);
+
+select cc, cv, pv, base from gojv order by cc;
+→ [{"cc":1,"cv":100,"pv":20,"base":10}]
+
+update gojv set pv = 777 where cc = 1;
+-- error: is a computed (non-invertible) expression and is read-only
+
+select cc, cv, pv, base from gojv order by cc;
+→ [{"cc":1,"cv":100,"pv":20,"base":10}]
+
+update gojv set base = 50 where cc = 1;
+
+select cc, cv, pv, base from gojv order by cc;
+→ [{"cc":1,"cv":100,"pv":100,"base":50}]
+
+drop view gojv;
+drop table gojc;
+drop table gojp;