@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/51.5-materialized-views-coarsened-key.sqllogic

@@ -0,0 +1,198 @@
+-- 51.5-materialized-views-coarsened-key.sqllogic — coarsened backing key: the
+-- collation-weakening parallel-migration shape (docs/migration.md § Convergence
+-- hazards). A body with no provable unique key whose source primary key survives
+-- through value-preserving passthrough lineage (bare column / collate / no-op
+-- cast) is keyed on the coarsened lineage key K' instead of rejected. The create
+-- emits the key-coarsening warning (record stamp covered in
+-- coarsened-backing-key.spec.ts); behavior contract pinned here:
+--   * create-fill stays LOUD on colliding seed data ("must be a set");
+--   * steady-state row-time maintenance merges colliding source rows
+--     last-writer-wins (deterministic oscillation until the sources are merged);
+--   * a delete of one colliding sibling deletes the shared derived row while the
+--     sibling source row lives (the documented anomaly); the sibling's next edit
+--     or a REFRESH re-asserts it;
+--   * REFRESH during a collision window is loud (it is a re-fill — same posture
+--     as create-fill).
+--
+-- Source text PKs are declared `collate binary` explicitly so the case-variant
+-- fixtures key identically cross-module (the store host reconciles
+-- implicit-collation text PKs to its table-level key collation, NOCASE by
+-- default, which would reject the colliding source rows at the SOURCE insert).
+
+-- ===================================
+-- 1. The migration shape creates over clean data (was: bag rejection)
+-- ===================================
+
+create table contact_v1 (handle text collate binary primary key, email text);
+insert into contact_v1 values ('Bob', 'bob@x.test'), ('Carol', 'carol@x.test');
+
+create materialized view contact_v2 as select handle collate nocase as handle, email from contact_v1;
+
+select handle, email from contact_v2 order by handle;
+→ [{"handle":"Bob","email":"bob@x.test"},{"handle":"Carol","email":"carol@x.test"}]
+
+-- ===================================
+-- 2. Colliding seed data still fails loudly at fill (the at-deploy rejection)
+-- ===================================
+
+create table dup_src (handle text collate binary primary key);
+insert into dup_src values ('Bob'), ('bob');
+create materialized view dup_v2 as select handle collate nocase as handle from dup_src;
+-- error: must be a set
+
+-- nothing half-registered: the name is free again
+create table dup_v2 (x integer primary key);
+drop table dup_v2;
+
+-- ===================================
+-- 3. Steady state: a colliding source insert LWW-merges into the shared derived
+--    row, and each sibling edit re-asserts its own image (deterministic oscillation)
+-- ===================================
+
+insert into contact_v1 values ('CAROL', 'caps@x.test');
+select count(*) as n from contact_v1;
+→ [{"n":3}]
+
+-- the two case-variants share one NOCASE backing key — last writer won
+select count(*) as n from contact_v2;
+→ [{"n":2}]
+select handle, email from contact_v2 where handle = 'carol';
+→ [{"handle":"CAROL","email":"caps@x.test"}]
+
+-- an edit of the other sibling re-asserts ITS image into the shared key
+update contact_v1 set email = 'carol2@x.test' where handle = 'Carol';
+select handle, email from contact_v2 where handle = 'carol';
+→ [{"handle":"Carol","email":"carol2@x.test"}]
+
+-- REFRESH is a re-fill: during a collision window it is loud, like create-fill
+refresh materialized view contact_v2;
+-- error: must be a set
+
+-- ===================================
+-- 4. Delete-one-sibling anomaly: the shared derived row vanishes while the
+--    sibling source row lives; REFRESH recovers it
+-- ===================================
+
+delete from contact_v1 where handle = 'CAROL';
+select count(*) as n from contact_v1;
+→ [{"n":2}]
+-- 'Carol' still lives in the source, but its derived row is gone (documented anomaly)
+select count(*) as n from contact_v2;
+→ [{"n":1}]
+
+refresh materialized view contact_v2;
+select handle, email from contact_v2 order by handle;
+→ [{"handle":"Bob","email":"bob@x.test"},{"handle":"Carol","email":"carol2@x.test"}]
+
+-- the surviving sibling's next edit also recovers, without a refresh
+insert into contact_v1 values ('DAVE', 'dave@x.test');
+insert into contact_v1 values ('dave', 'dave2@x.test');
+select email from contact_v2 where handle = 'dave';
+→ [{"email":"dave2@x.test"}]
+delete from contact_v1 where handle = 'dave';
+select count(*) as n from contact_v2 where handle = 'dave';
+→ [{"n":0}]
+update contact_v1 set email = 'dave3@x.test' where handle = 'DAVE';
+select handle, email from contact_v2 where handle = 'dave';
+→ [{"handle":"DAVE","email":"dave3@x.test"}]
+
+-- ===================================
+-- 5. Multi-column passthrough body (cannot be grouped) — composite coarsened key
+-- ===================================
+
+create table mc (a text collate binary, b text collate binary, v integer, primary key (a, b));
+insert into mc values ('X', '1', 10), ('Y', '1', 20);
+create materialized view mc_v as select a collate nocase as a, b, v from mc;
+select a, b, v from mc_v order by a, b;
+→ [{"a":"X","b":"1","v":10},{"a":"Y","b":"1","v":20}]
+
+-- distinct b keeps case-variants apart…
+insert into mc values ('x', '2', 30);
+select count(*) as n from mc_v;
+→ [{"n":3}]
+
+-- …while a same-b case-variant LWW-merges
+insert into mc values ('y', '1', 40);
+select count(*) as n from mc_v;
+→ [{"n":3}]
+select v from mc_v where a = 'y' and b = '1';
+→ [{"v":40}]
+
+-- ===================================
+-- 6. A key-dropping projection still keeps the bag rejection
+-- ===================================
+
+create materialized view still_bag as select email from contact_v1;
+-- error: no provable unique key
+
+-- A collated GROUP BY key registers with a REAL (non-coarsened) key: the group
+-- columns genuinely key the aggregate output, published under exactly their
+-- grouping (NOCASE) collation (ticket collated-groupby-key-completeness — the
+-- non-coarsened complement to this file's coarsened-lineage shape). Here
+-- contact_v1 = {Bob, Carol, DAVE} with no NOCASE collisions, so three groups.
+create materialized view grp_bag as select handle collate nocase as h, count(*) as n from contact_v1 group by handle collate nocase;
+select h, n from grp_bag order by h;
+→ [{"h":"Bob","n":1},{"h":"Carol","n":1},{"h":"DAVE","n":1}]
+
+-- ===================================
+-- 7. Refining direction (BINARY output over a NOCASE-keyed source) is a true
+--    unique key — accepted silently, byte-exact backing keys
+-- ===================================
+
+create table nck (h text collate nocase primary key, v integer);
+insert into nck values ('Bob', 1);
+create materialized view nck_v as select h collate binary as h, v from nck;
+select h, v from nck_v;
+→ [{"h":"Bob","v":1}]
+
+-- ===================================
+-- 8. An ORDER BY coarsened body keeps the contract: the ordering seed is
+--    suppressed so the backing keys on K' alone — colliding seed data stays
+--    LOUD and a colliding insert still LWW-merges (with the seed, the widened
+--    physical key would have admitted both siblings silently)
+-- ===================================
+
+create table ord_src (handle text collate binary primary key, email text);
+insert into ord_src values ('Bob', 'b@x.test'), ('bob', 'b2@x.test');
+create materialized view ord_v as select handle collate nocase as handle, email from ord_src order by email;
+-- error: must be a set
+
+delete from ord_src where handle = 'bob';
+create materialized view ord_v as select handle collate nocase as handle, email from ord_src order by email;
+insert into ord_src values ('BOB', 'b3@x.test');
+select handle, email from ord_v;
+→ [{"handle":"BOB","email":"b3@x.test"}]
+
+-- ===================================
+-- 9. Explicit-collation backing key survives the store reconcile
+--    (ticket join-key-collation-resolution-alignment): an MV column published with
+--    an EXPLICIT collation now stamps `ColumnSchema.collationExplicit`, so the store
+--    module keys the backing PK under the PUBLISHED collation instead of re-keying
+--    every implicit text PK under its table-level default (NOCASE). A body whose key
+--    column is explicit `collate binary` must therefore keep case-variant rows that
+--    are DISTINCT under BINARY but would collide under the store default — proving
+--    the published collation, not the store default, governs the backing key. (Under
+--    the memory module the backing already keys on the column's collation field; this
+--    case earns its keep under `yarn test:store`.)
+-- ===================================
+
+create table bin_src (handle text collate binary primary key, v integer);
+insert into bin_src values ('Bob', 1), ('bob', 2);
+create materialized view bin_v as select handle collate binary as handle, v from bin_src;
+
+-- Both case-variants survive: 'Bob' and 'bob' are distinct under the published
+-- BINARY key. A NOCASE re-key (the historic implicit-default reconcile) would have
+-- collapsed them to one row (or rejected the fill as "not a set").
+select count(*) as n from bin_v;
+→ [{"n":2}]
+select handle, v from bin_v order by v;
+→ [{"handle":"Bob","v":1},{"handle":"bob","v":2}]
+
+-- A genuinely-implicit (default-collation) MV column keeps the historic behavior:
+-- no explicit stamp, so the store applies its table-level default. Pin the
+-- value-level result (collation-agnostic) so the case runs identically cross-module.
+create table plain_src (id integer primary key, label text);
+insert into plain_src values (1, 'Xyz'), (2, 'abc');
+create materialized view plain_v as select id, label from plain_src;
+select id, label from plain_v order by id;
+→ [{"id":1,"label":"Xyz"},{"id":2,"label":"abc"}]

package/test/logic/51.7-maintained-table-attach-detach.sqllogic

@@ -0,0 +1,468 @@
+-- 51.7-maintained-table-attach-detach.sqllogic — the maintained-table lifecycle
+-- verbs: `create table … maintained as <body>` (declared-shape attach-to-empty),
+-- `alter table … set maintained as <body>` (attach / re-attach with
+-- verify-by-diff reconcile — derived content wins, identical content writes
+-- nothing), and `alter table … drop maintained` (detach — catalog-only, rows
+-- intact, table becomes ordinary and writable).
+
+-- ===================================
+-- 1. create table … maintained as — declared-shape form ≡ create-MV
+-- ===================================
+
+create table src (id integer primary key, v text);
+insert into src values (1, 'a'), (2, 'b');
+
+create table mt (id integer primary key, v text) maintained as select id, v from src;
+
+select * from mt order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+-- row-time maintenance is live: source writes reflect immediately
+insert into src values (3, 'c');
+select * from mt order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"},{"id":3,"v":"c"}]
+
+update src set v = 'B' where id = 2;
+select v from mt where id = 2;
+→ [{"v":"B"}]
+
+delete from src where id = 3;
+select count(*) as n from mt;
+→ [{"n":2}]
+
+-- write-through: DML against the maintained table routes to the source
+insert into mt values (9, 'z');
+select v from src where id = 9;
+→ [{"v":"z"}]
+delete from mt where id = 9;
+
+-- refresh works on a table-form maintained table
+refresh materialized view mt;
+select count(*) as n from mt;
+→ [{"n":2}]
+
+-- structural ALTER is rejected: the shape is body-defined
+alter table mt add column extra text;
+-- error: materialized view
+
+-- drop materialized view drops the one unified record
+drop materialized view mt;
+select count(*) as n from src;
+→ [{"n":2}]
+
+-- ===================================
+-- 2. Declared-shape mismatches error before any catalog registration
+-- ===================================
+
+create table src2 (id integer primary key, v text not null);
+insert into src2 values (1, 'a');
+
+-- arity (build-time gate)
+create table mt2 (id integer primary key, v text not null, extra integer) maintained as select id, v from src2;
+-- error: body produces 2 columns
+
+-- column name (strict: alias the body to the declared shape)
+create table mt2 (id integer primary key, vv text not null) maintained as select id, v from src2;
+-- error: alias the body output
+
+-- type
+create table mt2 (id integer primary key, v integer not null) maintained as select id, v from src2;
+-- error: body derives type
+
+-- not-null (strict in both directions; here the body derives not null but the
+-- declared column is explicitly nullable)
+create table mt2 (id integer primary key, v text null) maintained as select id, v from src2;
+-- error: nullable
+
+-- collation
+create table mt2 (id integer primary key, v text not null collate nocase) maintained as select id, v from src2;
+-- error: collation
+
+-- physical PK column
+create table mt2 (id integer not null, v text not null primary key) maintained as select id, v from src2;
+-- error: primary-key component
+
+-- physical PK direction
+create table mt2 (id integer primary key desc, v text not null) maintained as select id, v from src2;
+-- error: direction
+
+-- nothing registered by the failures: the name stayed free and a plain create works
+create table mt2 (id integer primary key, v text not null);
+insert into mt2 values (1, 'x');
+drop table mt2;
+
+-- if not exists interplay: an existing table skips ENTIRELY — never half-attaches
+create table keepme (id integer primary key, v text not null);
+insert into keepme values (1, 'orig');
+create table if not exists keepme (id integer primary key, v text not null) maintained as select id, v from src2;
+select * from keepme order by id;
+→ [{"id":1,"v":"orig"}]
+-- still plain (no derivation was attached) and still writable
+alter table keepme drop maintained;
+-- error: not a maintained table
+insert into keepme values (2, 'still writable');
+drop table keepme;
+
+-- ===================================
+-- 3. set maintained — fresh attach reconciles by diff (derived content wins)
+-- ===================================
+
+create table base (id integer primary key, v text not null);
+insert into base values (1, 'a'), (2, 'b'), (3, 'c');
+
+-- the upgrading-peer case: the target exists with drifted content —
+-- row 1 identical (no write), row 2 lagged (update), row 3 missing (insert),
+-- row 4 extra (delete)
+create table tgt (id integer primary key, v text not null);
+insert into tgt values (1, 'a'), (2, 'STALE'), (4, 'EXTRA');
+
+alter table tgt set maintained as select id, v from base;
+
+select * from tgt order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"},{"id":3,"v":"c"}]
+
+-- maintenance resumed: source writes propagate
+insert into base values (5, 'e');
+select v from tgt where id = 5;
+→ [{"v":"e"}]
+
+-- the attached table is write-through, like any maintained table
+update tgt set v = 'A' where id = 1;
+select v from base where id = 1;
+→ [{"v":"A"}]
+
+-- structural ALTER now rejected
+alter table tgt add column x integer;
+-- error: materialized view
+
+-- ===================================
+-- 4. detach round-trip: detach → user writes → re-attach reconciles the drift
+-- ===================================
+
+alter table tgt drop maintained;
+
+-- rows intact
+select count(*) as n from tgt;
+→ [{"n":4}]
+
+-- maintenance stopped: a source write no longer propagates
+insert into base values (6, 'f');
+select count(*) as n from tgt where id = 6;
+→ [{"n":0}]
+
+-- ordinary and user-writable: a direct write stays local (no write-through).
+-- After detach the table carries no derivation, so the engine's READONLY backstop
+-- (runtime DML executor) sheds with it — a direct INSERT/UPDATE/DELETE succeeds and
+-- writes the table's own rows rather than routing to a source.
+insert into tgt values (7, 'local');
+select count(*) as n from base where id = 7;
+→ [{"n":0}]
+-- the local row is readable directly in the detached (now ordinary) table
+select v from tgt where id = 7;
+→ [{"v":"local"}]
+update tgt set v = 'LOCAL' where id = 7;
+select v from tgt where id = 7;
+→ [{"v":"LOCAL"}]
+delete from tgt where id = 7;
+select count(*) as n from tgt where id = 7;
+→ [{"n":0}]
+
+-- structural ALTER allowed again
+alter table tgt add column extra text null;
+alter table tgt drop column extra;
+
+-- re-attach reconciles exactly the user-written drift; maintenance resumes
+alter table tgt set maintained as select id, v from base;
+select * from tgt order by id;
+→ [{"id":1,"v":"A"},{"id":2,"v":"b"},{"id":3,"v":"c"},{"id":5,"v":"e"},{"id":6,"v":"f"}]
+insert into base values (8, 'h');
+select v from tgt where id = 8;
+→ [{"v":"h"}]
+
+-- ===================================
+-- 5. re-attach replaces the body atomically (the differ's body-change primitive)
+-- ===================================
+
+create table base2 (id integer primary key, v text not null);
+insert into base2 values (100, 'x');
+
+alter table tgt set maintained as select id, v from base2;
+select * from tgt order by id;
+→ [{"id":100,"v":"x"}]
+
+-- the old source no longer drives it
+insert into base values (9, 'i');
+select count(*) as n from tgt;
+→ [{"n":1}]
+
+-- the new source does
+insert into base2 values (101, 'y');
+select * from tgt order by id;
+→ [{"id":100,"v":"x"},{"id":101,"v":"y"}]
+
+alter table tgt drop maintained;
+drop table tgt;
+drop table base2;
+
+-- an aggregate body attaches too: the strict shape check holds over the
+-- derived aggregate types/key, and incremental maintenance runs post-attach.
+create table words (id integer primary key, w text not null);
+insert into words values (1, 'x'), (2, 'y'), (3, 'x');
+-- the PK column pins `collate binary` so the declared collation matches the
+-- body-derived one under both suites (the store's key collation defaults to NOCASE)
+create table counts (w text not null collate binary primary key, n integer not null);
+alter table counts set maintained as select w, count(*) as n from words group by w;
+select * from counts order by w;
+→ [{"w":"x","n":2},{"w":"y","n":1}]
+insert into words values (4, 'x');
+select n from counts where w = 'x';
+→ [{"n":3}]
+delete from words where id = 2;
+select count(*) as remaining from counts;
+→ [{"remaining":1}]
+drop materialized view counts;
+drop table words;
+
+-- ===================================
+-- 6. duplicate derived keys ⇒ loud reject, table and catalog untouched
+--    (the coarsened-key collision — the parallel-migration shape)
+-- ===================================
+
+-- the source PK is `collate binary` explicitly so the case-variant pair inserts
+-- under both suites (the store's table-level key collation defaults to NOCASE)
+create table contacts (handle text collate binary primary key, email text not null);
+insert into contacts values ('alice', 'a@x'), ('ALICE', 'A@X');
+
+-- create path: the loud reject rolls the whole record back
+create table contacts2 (handle text not null collate nocase primary key, email text not null)
+  maintained as select handle collate nocase as handle, email from contacts;
+-- error: duplicate rows for primary key
+
+-- the name stayed free
+create table contacts2 (handle text not null collate nocase primary key, email text not null);
+insert into contacts2 values ('z', 'z@x');
+
+-- attach path: same reject, table and catalog untouched
+alter table contacts2 set maintained as select handle collate nocase as handle, email from contacts;
+-- error: duplicate rows for primary key
+select * from contacts2 order by handle;
+→ [{"handle":"z","email":"z@x"}]
+insert into contacts2 values ('w', 'w@x');
+
+-- merge the collision in the source; the coarsened-key attach then succeeds
+-- (derived wins: the local rows are replaced by the derived contents)
+delete from contacts where handle = 'ALICE';
+alter table contacts2 set maintained as select handle collate nocase as handle, email from contacts;
+select * from contacts2 order by handle;
+→ [{"handle":"alice","email":"a@x"}]
+
+drop materialized view contacts2;
+drop table contacts;
+
+-- ===================================
+-- 7. self-reference and cycles via attach are rejected; the consumer cascade
+--    sees exactly the reconcile diff
+-- ===================================
+
+create table a1 (id integer primary key, v text not null);
+insert into a1 values (1, 'a');
+
+-- self-reference
+alter table a1 set maintained as select id, v from a1;
+-- error: derivation cycle
+
+-- two-table cycle: b1 maintained from a1, then a1 from b1 would close the loop
+create table b1 (id integer primary key, v text not null);
+alter table b1 set maintained as select id, v from a1;
+select * from b1 order by id;
+→ [{"id":1,"v":"a"}]
+alter table a1 set maintained as select id, v from b1;
+-- error: derivation cycle
+
+-- a non-cyclic body over the same table works (c1 → a1 → b1 chain), and the
+-- attach reconcile's changes cascade to the consumer
+create table c1 (id integer primary key, v text not null);
+insert into c1 values (5, 'c');
+alter table a1 set maintained as select id, v from c1;
+select * from a1 order by id;
+→ [{"id":5,"v":"c"}]
+select * from b1 order by id;
+→ [{"id":5,"v":"c"}]
+
+-- steady-state writes flow down the whole chain
+insert into c1 values (6, 'd');
+select * from b1 order by id;
+→ [{"id":5,"v":"c"},{"id":6,"v":"d"}]
+
+drop materialized view b1;
+drop materialized view a1;
+drop table c1;
+
+-- ===================================
+-- 8. verb errors
+-- ===================================
+
+create table plain1 (id integer primary key);
+
+alter table plain1 drop maintained;
+-- error: not a maintained table
+
+-- a DML body is rejected at build (and the mutation never executes)
+alter table plain1 set maintained as insert into base values (99, 'x') returning id;
+-- error: cannot be used as a view body
+select count(*) as n from base where id = 99;
+→ [{"n":0}]
+
+-- a shape-differing attach over a PLAIN table (the implicit form) RESHAPES the
+-- backing to follow the body — here a trailing append; the plain rows are
+-- discarded by the reconcile (derived content wins)
+alter table plain1 set maintained as select id, v from base;
+select count(*) as n from plain1;
+→ [{"n":7}]
+alter table plain1 drop maintained;
+
+-- an INEXPRESSIBLE reshape (a column reorder) is a sited error, table untouched
+alter table plain1 set maintained as select v, id from base;
+-- error: changed incompatibly
+select count(*) as n from plain1;
+→ [{"n":7}]
+
+-- a generated column is rejected on both authoring forms: the body supplies
+-- every column's value, so the generation expression would silently diverge
+create table gen1 (id integer primary key, v text not null generated always as ('x'));
+alter table gen1 set maintained as select id, v from base;
+-- error: generated
+drop table gen1;
+create table gen1 (id integer primary key, v text not null generated always as ('x')) maintained as select id, v from base;
+-- error: generated
+
+drop table plain1;
+drop table base;
+
+-- ===================================
+-- 9. detach of a STALE maintained table is allowed — the flag leaves with the
+--    derivation
+-- ===================================
+
+create table src3 (id integer primary key, v text not null);
+insert into src3 values (1, 'a');
+create table mt3 (id integer primary key, v text not null) maintained as select id, v from src3;
+
+-- an incompatible source change (dropping a referenced column) marks the
+-- consumer stale
+alter table src3 drop column v;
+select * from mt3;
+-- error: stale
+
+alter table mt3 drop maintained;
+
+-- plain again: readable and writable, staleness gone with the derivation
+select * from mt3 order by id;
+→ [{"id":1,"v":"a"}]
+insert into mt3 values (2, 'b');
+drop table mt3;
+drop table src3;
+
+-- ===================================
+-- 10. with defaults clause on the table form (write-through supplies the
+--     omitted column)
+-- ===================================
+
+create table src4 (id integer primary key, v text not null, created integer not null);
+create table mt4 (id integer primary key, v text not null, created integer not null)
+  maintained as select id, v, created from src4
+  with defaults (created = 42);
+
+insert into mt4 (id, v) values (1, 'a');
+select * from src4;
+→ [{"id":1,"v":"a","created":42}]
+select * from mt4;
+→ [{"id":1,"v":"a","created":42}]
+
+drop materialized view mt4;
+
+-- the clause also rides the attach verb
+create table mt5 (id integer primary key, v text not null, created integer not null);
+alter table mt5 set maintained as select id, v, created from src4
+  with defaults (created = 99);
+insert into mt5 (id, v) values (2, 'b');
+select * from src4 order by id;
+→ [{"id":1,"v":"a","created":42},{"id":2,"v":"b","created":99}]
+select created from mt5 where id = 2;
+→ [{"created":99}]
+
+drop materialized view mt5;
+drop table src4;
+
+-- ===================================
+-- 11. `maintained` stays contextual — usable as an identifier
+-- ===================================
+
+create table maintained (maintained integer primary key);
+insert into maintained values (1);
+select maintained from maintained;
+→ [{"maintained":1}]
+-- the bare DROP MAINTAINED verb wins over a column of that name…
+alter table maintained drop maintained;
+-- error: not a maintained table
+drop table maintained;
+
+-- ===================================
+-- 12. set maintained (cols) as — explicit rename-list re-attach + backing reshape
+-- ===================================
+
+create table rsrc (id integer primary key, x text not null, y text not null);
+insert into rsrc values (1, 'a', 'A'), (2, 'b', 'B');
+
+-- explicit attach with an authored rename list (a, b) over the body's (id, x)
+create table rmv (a integer primary key, b text not null) maintained (a, b) as select id, x from rsrc;
+select a, b from rmv order by a;
+→ [{"a":1,"b":"a"},{"a":2,"b":"b"}]
+
+-- rename-list change b → c (same body): the backing column is RENAMED in place,
+-- rows relabeled (not rebuilt); the derivation re-records (a, c)
+alter table rmv set maintained (a, c) as select id, x from rsrc;
+select a, c from rmv order by a;
+→ [{"a":1,"c":"a"},{"a":2,"c":"b"}]
+
+-- idempotent: re-running the same verb changes nothing
+alter table rmv set maintained (a, c) as select id, x from rsrc;
+select a, c from rmv order by a;
+→ [{"a":1,"c":"a"},{"a":2,"c":"b"}]
+
+-- maintenance is live on the renamed backing
+insert into rsrc values (3, 'c', 'C');
+select c from rmv where a = 3;
+→ [{"c":"c"}]
+
+-- body-only change with the list unchanged applies (a plain reconcile, no reshape)
+alter table rmv set maintained (a, c) as select id, y from rsrc;
+select a, c from rmv order by a;
+→ [{"a":1,"c":"A"},{"a":2,"c":"B"},{"a":3,"c":"C"}]
+
+-- a rename-list swap (a, c) → (c, a) is an inexpressible reorder, table untouched
+alter table rmv set maintained (c, a) as select id, y from rsrc;
+-- error: changed incompatibly
+select a, c from rmv order by a;
+→ [{"a":1,"c":"A"},{"a":2,"c":"B"},{"a":3,"c":"C"}]
+
+-- a list/body arity mismatch is a sited error before anything is recorded
+alter table rmv set maintained (a, c, d) as select id, y from rsrc;
+-- error: rename list declares 3 columns but the body produces 2
+
+-- a count drift (3-col list + body over the 2-col table) is the strict shape error
+alter table rmv set maintained (a, c, d) as select id, y, x from rsrc;
+-- error: body produces 3 columns but the table declares 2
+
+-- still intact after the rejected re-attaches
+select a, c from rmv order by a;
+→ [{"a":1,"c":"A"},{"a":2,"c":"B"},{"a":3,"c":"C"}]
+
+-- the bare verb over the explicit table goes implicit: the backing relabels to the
+-- body's natural names and the recorded list is abandoned (derivation.columns clears)
+alter table rmv set maintained as select id, x from rsrc;
+select id, x from rmv order by id;
+→ [{"id":1,"x":"a"},{"id":2,"x":"b"},{"id":3,"x":"c"}]
+
+drop materialized view rmv;
+drop table rsrc;