@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.7-alter-column-collate.sqllogic

@@ -0,0 +1,105 @@
+-- ALTER TABLE ALTER COLUMN ... SET COLLATE — change a column's collation in place.
+-- This file covers the query-layer semantics that derive purely from the column
+-- schema collation (ORDER BY / `=` follow the new collation), the table_info
+-- round-trip, unknown-collation rejection, set-back-to-BINARY, and idempotent
+-- re-apply. All of these update + re-register the column schema, so they run under
+-- BOTH the memory module (`yarn test`) and the store module (`yarn test:store`).
+--
+-- Structure re-sort + existing-row uniqueness re-validation (memory-specific) live
+-- in 41.7.1-alter-column-collate-unique.sqllogic.
+
+-- ===================================
+-- 1. SET COLLATE NOCASE changes `=` semantics on a non-key column.
+-- ===================================
+
+create table t_eq (id integer primary key, name text);
+insert into t_eq values (1, 'abc'), (2, 'ABC'), (3, 'abd');
+
+-- Under BINARY, only the exact 'ABC' matches.
+select count(*) as n from t_eq where name = 'ABC';
+→ [{"n":1}]
+
+alter table t_eq alter column name set collate nocase;
+
+-- Under NOCASE, both 'abc' and 'ABC' equal 'ABC'.
+select count(*) as n from t_eq where name = 'ABC';
+→ [{"n":2}]
+
+drop table t_eq;
+
+-- ===================================
+-- 2. SET COLLATE NOCASE changes ORDER BY on a non-key column.
+-- ===================================
+
+create table t_ord (id integer primary key, name text);
+insert into t_ord values (1, 'b'), (2, 'A'), (3, 'C');
+
+-- BINARY: all uppercase sort before lowercase → A, C, b
+select name from t_ord order by name;
+→ [{"name":"A"},{"name":"C"},{"name":"b"}]
+
+alter table t_ord alter column name set collate nocase;
+
+-- NOCASE: case-folded order → A, b, C
+select name from t_ord order by name;
+→ [{"name":"A"},{"name":"b"},{"name":"C"}]
+
+drop table t_ord;
+
+-- ===================================
+-- 3. table_info round-trip; set-back-to-BINARY clears it.
+-- ===================================
+
+create table t_ti (id integer primary key, name text);
+
+select name, collation from table_info('t_ti') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"BINARY"}]
+
+alter table t_ti alter column name set collate nocase;
+select name, collation from table_info('t_ti') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"NOCASE"}]
+
+-- the canonical UPPERCASE spelling round-trips identically
+alter table t_ti alter column name set collate RTRIM;
+select name, collation from table_info('t_ti') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"RTRIM"}]
+
+-- SET COLLATE BINARY restores the default
+alter table t_ti alter column name set collate binary;
+select name, collation from table_info('t_ti') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"BINARY"}]
+
+drop table t_ti;
+
+-- ===================================
+-- 4. Unknown / unsupported collation rejected (same error shape as CREATE TABLE).
+-- ===================================
+
+create table t_bad (id integer primary key, name text);
+-- run
+
+alter table t_bad alter column name set collate nosuchcollation;
+-- error: Unknown collation 'nosuchcollation' for type 'TEXT'
+
+-- the rejected ALTER left the column untouched
+select name, collation from table_info('t_bad') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"BINARY"}]
+
+drop table t_bad;
+
+-- ===================================
+-- 5. Idempotent: re-applying the same collation is a harmless no-op.
+-- ===================================
+
+create table t_idem (id integer primary key, name text);
+insert into t_idem values (1, 'a'), (2, 'B');
+alter table t_idem alter column name set collate nocase;
+alter table t_idem alter column name set collate nocase;
+
+select name, collation from table_info('t_idem') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"NOCASE"}]
+
+select name from t_idem order by name;
+→ [{"name":"a"},{"name":"B"}]
+
+drop table t_idem;

package/test/logic/41.7.1-alter-column-collate-unique.sqllogic

@@ -0,0 +1,45 @@
+-- ALTER COLUMN ... SET COLLATE — PRIMARY KEY re-key collision (cross-module).
+--
+-- CROSS-MODULE (NOT in MEMORY_ONLY_FILES): runs in both memory and store modes.
+-- Both modules enforce PRIMARY KEY uniqueness/ordering under a PER-COLUMN collation
+-- and re-key the primary structure on an ALTER COLUMN SET COLLATE of a PK member —
+-- memory re-keys its primary tree, the store physically re-encodes its data-store
+-- keys (and rebuilds dependent secondary indexes). So a PK pair distinct under
+-- BINARY but colliding under NOCASE rejects the ALTER with CONSTRAINT on both,
+-- leaving the table unchanged and still BINARY.
+--
+-- The PK column is declared `collate binary` EXPLICITLY: the store's table-level
+-- default key collation K is NOCASE, so an undecorated text PK would be keyed NOCASE
+-- and could not even hold the 'a'/'A' pair. The explicit BINARY declaration is
+-- honored natively by the store's per-column key encoding (ticket
+-- store-pk-collate-physical-rekey), which is what makes this fixture runnable
+-- cross-module. On memory `collate binary` matches its BINARY column default, so the
+-- declaration is a no-op there.
+--
+-- The non-PK UNIQUE / CREATE UNIQUE INDEX sections (identical across both modules)
+-- live in 41.7.2-alter-column-collate-unique-store.sqllogic, which also covers a
+-- divergent PK collation change that is HONORED (re-keyed, non-colliding). The
+-- cross-module query-layer behavior lives in 41.7-alter-column-collate.sqllogic.
+
+-- ===================================
+-- 1. PK column collation change re-keys the primary structure; a PK that is
+--    unique under BINARY but collides under NOCASE is rejected, all-or-nothing.
+-- ===================================
+
+create table pkc (k text collate binary primary key);
+insert into pkc values ('a'), ('A');
+-- run
+
+alter table pkc alter column k set collate nocase;
+-- error: UNIQUE constraint failed
+
+-- rollback: both rows survive, column still BINARY (BINARY order: A before a)
+select k from pkc order by k;
+→ [{"k":"A"},{"k":"a"}]
+
+-- the table is still writable after the failed ALTER
+insert into pkc values ('B');
+select count(*) as n from pkc;
+→ [{"n":3}]
+
+drop table pkc;

package/test/logic/41.7.2-alter-column-collate-unique-store.sqllogic

@@ -0,0 +1,208 @@
+-- ALTER COLUMN ... SET COLLATE — cross-module existing-row re-validation.
+--
+-- CROSS-MODULE (NOT in MEMORY_ONLY_FILES): runs in both memory and store modes.
+-- Sections 1-8: a per-column collation change is re-validated against existing rows
+-- for every non-PK UNIQUE constraint covering the altered column (inline / table-level
+-- here; the CREATE UNIQUE INDEX-derived cases are in
+-- 41.7.2.1-alter-column-collate-unique-index-store): a value set distinct under BINARY but colliding under
+-- NOCASE rejects the ALTER with CONSTRAINT (schema unchanged), and a distinct set
+-- succeeds and then enforces under the new collation. The store reaches end-to-end
+-- parity with memory here because the constrained column is row DATA keyed by the
+-- integer PK, so the store's fixed-table-collation KEY encoding is irrelevant — both
+-- modules behave identically.
+--
+-- Section 9: a PRIMARY KEY column's collation change runs cross-module. Both modules
+-- key the PK per-column and re-key the primary structure on SET COLLATE — memory
+-- re-keys its primary tree, the store physically re-encodes its data-store keys and
+-- rebuilds dependent secondary indexes (ticket store-pk-collate-physical-rekey). §9
+-- exercises a NON-colliding divergent change (NOCASE→BINARY) that is HONORED: a
+-- case-distinct PK that NOCASE collapsed now coexists, and ordering/uniqueness follow
+-- BINARY. The COLLIDING divergent case ('a'/'A' under BINARY→NOCASE rejects with
+-- CONSTRAINT, all-or-nothing) lives cross-module in
+-- 41.7.1-alter-column-collate-unique.sqllogic. The cross-module query-layer behavior
+-- lives in 41.7-alter-column-collate.sqllogic.
+
+-- ===================================
+-- 1. UNIQUE column, values distinct under BOTH collations → ALTER succeeds, and a
+--    subsequent NOCASE-colliding insert is then rejected under the new collation.
+-- ===================================
+
+create table us (id integer primary key, email text unique);
+insert into us values (1, 'a@x'), (2, 'b@x');
+
+alter table us alter column email set collate nocase;
+-- run
+
+-- the change took effect: a case-only duplicate now collides under NOCASE
+insert into us values (3, 'A@X');
+-- error: UNIQUE constraint failed
+
+select id, email from us order by id;
+→ [{"id":1,"email":"a@x"},{"id":2,"email":"b@x"}]
+
+-- a genuinely distinct value still inserts
+insert into us values (4, 'c@x');
+select id, email from us order by id;
+→ [{"id":1,"email":"a@x"},{"id":2,"email":"b@x"},{"id":4,"email":"c@x"}]
+
+drop table us;
+
+-- ===================================
+-- 2. UNIQUE column, values distinct under BINARY but COLLIDING under NOCASE →
+--    the ALTER is rejected with CONSTRAINT and the table is left unchanged.
+-- ===================================
+
+create table uc (id integer primary key, email text unique);
+insert into uc values (1, 'a@x'), (2, 'A@x');
+-- run
+
+alter table uc alter column email set collate nocase;
+-- error: UNIQUE constraint failed
+
+-- the rejected ALTER rolled back: both rows survive and the column is still BINARY,
+-- so the two case-distinct values remain valid
+select id, email from uc order by id;
+→ [{"id":1,"email":"a@x"},{"id":2,"email":"A@x"}]
+
+select name, collation from table_info('uc') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"email","collation":"BINARY"}]
+
+-- and the table is still writable after the failed ALTER
+insert into uc values (3, 'B@x');
+select count(*) as n from uc;
+→ [{"n":3}]
+
+drop table uc;
+
+-- ===================================
+-- 3-4. EXPLICIT `create unique index` (not an inline UNIQUE), re-validated by the
+--      same existing-row scan — rejecting on collision, honoring when distinct.
+-- ===================================
+-- Lives in 41.7.2.1-alter-column-collate-unique-index-store; needs standalone index DDL.
+
+-- ===================================
+-- 5. COMPOSITE UNIQUE (a, b) where only member `a`'s collation changes. Each member
+--    is normalized by its OWN column collation: after `a`→NOCASE, rows that differ
+--    only by the case of `a` collide; the still-BINARY `b` keeps distinguishing rows
+--    that differ in `b`'s case.
+-- ===================================
+
+-- 5a. distinct under BINARY (a: x vs X), colliding once `a` is NOCASE → ALTER rejected.
+create table cc (id integer primary key, a text, b text, unique (a, b));
+insert into cc values (1, 'x', 'y'), (2, 'X', 'y');
+-- run
+
+alter table cc alter column a set collate nocase;
+-- error: UNIQUE constraint failed
+
+-- rollback: both rows survive, `a` still BINARY
+select id, a, b from cc order by id;
+→ [{"id":1,"a":"x","b":"y"},{"id":2,"a":"X","b":"y"}]
+
+drop table cc;
+
+-- 5b. `a` differs only by case BUT `b` differs by case too → under (NOCASE a, BINARY b)
+--     the rows stay distinct (b is still BINARY) → ALTER succeeds, and the composite
+--     then enforces with `a` NOCASE / `b` BINARY.
+create table cd (id integer primary key, a text, b text, unique (a, b));
+insert into cd values (1, 'x', 'y'), (2, 'X', 'Y');
+
+alter table cd alter column a set collate nocase;
+-- run
+
+-- ('x','y') vs ('X','Y'): a collides under NOCASE, b ('y' vs 'Y') still distinguishes → OK
+select id, a, b from cd order by id;
+→ [{"id":1,"a":"x","b":"y"},{"id":2,"a":"X","b":"Y"}]
+
+-- now a NOCASE-on-a + exact-on-b duplicate collides
+insert into cd values (3, 'X', 'y');
+-- error: UNIQUE constraint failed
+
+-- but a row distinguished by b (still BINARY, value distinct from both rows) inserts fine
+insert into cd values (4, 'x', 'z');
+select count(*) as n from cd;
+→ [{"n":3}]
+
+drop table cd;
+
+-- ===================================
+-- 6. PARTIAL unique index — only rows the predicate accepts are re-validated.
+-- ===================================
+-- Lives in 41.7.2.1-alter-column-collate-unique-index-store: a partial UNIQUE can only
+-- be spelled as `create unique index … where …`, so it needs standalone index DDL.
+
+-- ===================================
+-- 7. NULL handling — SQL UNIQUE allows multiple NULLs, so existing NULL rows never
+--    count as collisions during the re-validation scan.
+-- ===================================
+
+create table nn (id integer primary key, email text null unique);
+insert into nn values (1, null), (2, null), (3, 'a@x');
+-- run
+
+alter table nn alter column email set collate nocase;
+-- run
+
+select name, collation from table_info('nn') where name = 'email';
+→ [{"name":"email","collation":"NOCASE"}]
+
+-- multiple NULLs still allowed after the change; a NOCASE duplicate still rejected
+insert into nn values (4, null);
+insert into nn values (5, 'A@X');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from nn;
+→ [{"n":4}]
+
+drop table nn;
+
+-- ===================================
+-- 8. NO-OP guard — setting the collation to the value it already has is a no-op that
+--    neither scans nor rejects (re-applying NOCASE after it is already NOCASE), even
+--    when existing rows would collide under some OTHER collation.
+-- ===================================
+
+create table nopg (id integer primary key, email text collate nocase unique);
+-- two rows distinct under NOCASE
+insert into nopg values (1, 'a@x'), (2, 'b@x');
+-- run
+
+-- idempotent re-apply: already NOCASE → returns the existing schema, no scan
+alter table nopg alter column email set collate nocase;
+-- run
+
+select name, collation from table_info('nopg') where name = 'email';
+→ [{"name":"email","collation":"NOCASE"}]
+
+-- still enforcing NOCASE afterward
+insert into nopg values (3, 'A@X');
+-- error: UNIQUE constraint failed
+
+drop table nopg;
+
+-- ===================================
+-- 9. PRIMARY KEY column, DIVERGENT collation change (NOCASE → BINARY) is HONORED
+--    cross-module via a physical re-key. The column is declared `collate nocase`
+--    EXPLICITLY so both modules start NOCASE-keyed (the store honors the explicit
+--    NOCASE per-column; memory keys NOCASE too). After re-keying to BINARY a
+--    case-distinct PK that NOCASE collapsed now coexists, and ordering/uniqueness
+--    follow BINARY. (The store re-keys per-column instead of rejecting the divergent
+--    change — ticket store-pk-collate-physical-rekey.)
+-- ===================================
+
+create table pkb (k text collate nocase primary key);
+insert into pkb values ('alpha'), ('beta');
+
+alter table pkb alter column k set collate binary;
+-- run
+
+-- under BINARY a case-distinct value now coexists (it would collide under NOCASE)
+insert into pkb values ('ALPHA');
+select k from pkb order by k;
+→ [{"k":"ALPHA"},{"k":"alpha"},{"k":"beta"}]
+
+-- an exact-duplicate PK still collides under BINARY
+insert into pkb values ('beta');
+-- error: UNIQUE constraint failed
+
+drop table pkb;

package/test/logic/41.7.2.1-alter-column-collate-unique-index-store.sqllogic

@@ -0,0 +1,114 @@
+-- 41.7.2.1-alter-column-collate-unique-index-store.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- ALTER COLUMN ... SET COLLATE re-validation where the UNIQUE comes from a standalone
+-- `create unique index`.
+--
+-- CROSS-MODULE (NOT in MEMORY_ONLY_FILES): runs in both memory and store modes, for the
+-- same reason as its parent — the constrained column is row DATA keyed by the integer PK,
+-- so the store's fixed-table-collation KEY encoding is irrelevant.
+--
+-- Carved out of 41.7.2-alter-column-collate-unique-store: sections 1, 2, 5, 7, 8 and 9
+-- there make the same re-validation points (reject on collision, honor when distinct,
+-- composite members, NULLs, no-op guard, PK re-key) with inline / table-level UNIQUE and
+-- need no index DDL. These sections need an explicit index — §1/§2 below because the
+-- constraint is index-derived rather than declared, §3 because a PARTIAL unique
+-- constraint has no declarative spelling in this engine.
+--
+-- Subject: an index-derived UNIQUE (including a partial one) is re-validated by the same
+-- existing-row scan on SET COLLATE, and afterwards enforces under the resulting collation.
+
+-- ===================================
+-- 1. EXPLICIT `create unique index` (not an inline UNIQUE) is re-validated by the
+--    same existing-row scan. A value set distinct under BINARY but colliding under
+--    NOCASE rejects the ALTER and rolls back; the table stays writable and the index
+--    keeps enforcing under the original collation.
+-- ===================================
+create table xi (id integer primary key, email text);
+create unique index xi_email on xi(email);
+insert into xi values (1, 'a@x'), (2, 'A@x');
+-- run
+
+alter table xi alter column email set collate nocase;
+-- error: UNIQUE constraint failed
+
+-- rollback: both rows survive, column still BINARY
+select id, email from xi order by id;
+→ [{"id":1,"email":"a@x"},{"id":2,"email":"A@x"}]
+
+select name, collation from table_info('xi') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"email","collation":"BINARY"}]
+
+-- the explicit unique index still enforces (under the original BINARY collation):
+-- a case-distinct value is still allowed, an exact duplicate is rejected.
+insert into xi values (3, 'B@x');
+select count(*) as n from xi;
+→ [{"n":3}]
+
+insert into xi values (4, 'a@x');
+-- error: UNIQUE constraint failed
+
+drop table xi;
+
+-- ===================================
+-- 2. EXPLICIT `create unique index`, distinct under BOTH collations → ALTER
+--    succeeds and the index then enforces under the NEW collation.
+-- ===================================
+
+create table xj (id integer primary key, email text);
+create unique index xj_email on xj(email);
+insert into xj values (1, 'a@x'), (2, 'b@x');
+
+alter table xj alter column email set collate nocase;
+-- run
+
+-- the index now enforces under NOCASE: a case-only duplicate collides
+insert into xj values (3, 'A@X');
+-- error: UNIQUE constraint failed
+
+select id, email from xj order by id;
+→ [{"id":1,"email":"a@x"},{"id":2,"email":"b@x"}]
+
+drop table xj;
+
+-- ===================================
+-- 3. PARTIAL unique index — only rows the predicate accepts are re-validated. A
+--    case-collision among EXCLUDED rows must NOT block the ALTER; a collision among
+--    INCLUDED rows must.
+-- ===================================
+
+-- 3a. the colliding pair is excluded by the predicate → ALTER succeeds.
+create table pp (id integer primary key, code text, active integer);
+create unique index pp_code on pp(code) where active = 1;
+insert into pp values (1, 'a', 0), (2, 'A', 0);
+-- run
+
+alter table pp alter column code set collate nocase;
+-- run
+
+-- the change took effect and the partial index now enforces NOCASE for active rows
+select name, collation from table_info('pp') where name = 'code';
+→ [{"name":"code","collation":"NOCASE"}]
+
+insert into pp values (3, 'a', 1);
+insert into pp values (4, 'A', 1);
+-- error: UNIQUE constraint failed
+
+drop table pp;
+
+-- 3b. the colliding pair is INCLUDED by the predicate → ALTER rejected, rollback.
+create table pq (id integer primary key, code text, active integer);
+create unique index pq_code on pq(code) where active = 1;
+insert into pq values (1, 'a', 1), (2, 'A', 1);
+-- run
+
+alter table pq alter column code set collate nocase;
+-- error: UNIQUE constraint failed
+
+select name, collation from table_info('pq') where name = 'code';
+→ [{"name":"code","collation":"BINARY"}]
+
+drop table pq;
+
+-- ===================================