@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/102-unique-constraints.sqllogic

@@ -0,0 +1,145 @@
+-- Tests for non-PK UNIQUE constraint enforcement
+
+-- === Basic UNIQUE column enforcement ===
+
+CREATE TABLE t_uc (id INTEGER PRIMARY KEY, email TEXT UNIQUE, name TEXT);
+INSERT INTO t_uc VALUES (1, 'alice@test.com', 'Alice');
+INSERT INTO t_uc VALUES (2, 'bob@test.com', 'Bob');
+-- run
+
+SELECT * FROM t_uc ORDER BY id;
+→ [{"id":1,"email":"alice@test.com","name":"Alice"},{"id":2,"email":"bob@test.com","name":"Bob"}]
+
+-- Duplicate UNIQUE value should fail
+INSERT INTO t_uc VALUES (3, 'alice@test.com', 'Eve');
+-- error: UNIQUE constraint failed
+
+-- Original data unchanged after failed insert
+SELECT count(*) as cnt FROM t_uc;
+→ [{"cnt":2}]
+
+-- === INSERT OR IGNORE with UNIQUE violation ===
+
+INSERT OR IGNORE INTO t_uc VALUES (4, 'alice@test.com', 'Ignored');
+SELECT count(*) as cnt FROM t_uc;
+→ [{"cnt":2}]
+
+-- === INSERT OR REPLACE with UNIQUE violation ===
+
+INSERT OR REPLACE INTO t_uc VALUES (5, 'alice@test.com', 'Replaced');
+SELECT * FROM t_uc ORDER BY id;
+→ [{"id":2,"email":"bob@test.com","name":"Bob"},{"id":5,"email":"alice@test.com","name":"Replaced"}]
+
+-- The old row (id=1) with the conflicting email was deleted
+SELECT count(*) as cnt FROM t_uc WHERE id = 1;
+→ [{"cnt":0}]
+
+DROP TABLE t_uc;
+-- run
+
+-- === NULL values in UNIQUE columns ===
+
+CREATE TABLE t_uc_null (id INTEGER PRIMARY KEY, code TEXT NULL UNIQUE);
+INSERT INTO t_uc_null VALUES (1, null);
+INSERT INTO t_uc_null VALUES (2, null);
+INSERT INTO t_uc_null VALUES (3, 'abc');
+-- run
+
+-- Multiple NULLs are allowed per SQL standard
+SELECT count(*) as cnt FROM t_uc_null;
+→ [{"cnt":3}]
+
+-- But duplicate non-NULL values still fail
+INSERT INTO t_uc_null VALUES (4, 'abc');
+-- error: UNIQUE constraint failed
+
+DROP TABLE t_uc_null;
+-- run
+
+-- === UPDATE changing UNIQUE column to conflicting value ===
+
+CREATE TABLE t_uc_upd (id INTEGER PRIMARY KEY, tag TEXT UNIQUE, val INTEGER);
+INSERT INTO t_uc_upd VALUES (1, 'alpha', 10);
+INSERT INTO t_uc_upd VALUES (2, 'beta', 20);
+-- run
+
+-- Updating to a conflicting UNIQUE value should fail
+UPDATE t_uc_upd SET tag = 'alpha' WHERE id = 2;
+-- error: UNIQUE constraint failed
+
+-- Data unchanged
+SELECT * FROM t_uc_upd ORDER BY id;
+→ [{"id":1,"tag":"alpha","val":10},{"id":2,"tag":"beta","val":20}]
+
+-- Updating non-UNIQUE column is fine
+UPDATE t_uc_upd SET val = 99 WHERE id = 2;
+-- run
+
+SELECT * FROM t_uc_upd ORDER BY id;
+→ [{"id":1,"tag":"alpha","val":10},{"id":2,"tag":"beta","val":99}]
+
+-- Updating UNIQUE column to its own value is fine (no conflict)
+UPDATE t_uc_upd SET tag = 'beta' WHERE id = 2;
+-- run
+
+SELECT * FROM t_uc_upd ORDER BY id;
+→ [{"id":1,"tag":"alpha","val":10},{"id":2,"tag":"beta","val":99}]
+
+-- Updating UNIQUE column to a new value is fine
+UPDATE t_uc_upd SET tag = 'gamma' WHERE id = 2;
+-- run
+
+SELECT * FROM t_uc_upd ORDER BY id;
+→ [{"id":1,"tag":"alpha","val":10},{"id":2,"tag":"gamma","val":99}]
+
+DROP TABLE t_uc_upd;
+-- run
+
+-- === Composite UNIQUE constraint ===
+
+CREATE TABLE t_uc_comp (
+    id INTEGER PRIMARY KEY,
+    a TEXT,
+    b INTEGER,
+    UNIQUE (a, b)
+);
+INSERT INTO t_uc_comp VALUES (1, 'x', 1);
+INSERT INTO t_uc_comp VALUES (2, 'x', 2);
+INSERT INTO t_uc_comp VALUES (3, 'y', 1);
+-- run
+
+-- Same combination should fail
+INSERT INTO t_uc_comp VALUES (4, 'x', 1);
+-- error: UNIQUE constraint failed
+
+-- Different combinations are fine
+SELECT count(*) as cnt FROM t_uc_comp;
+→ [{"cnt":3}]
+
+DROP TABLE t_uc_comp;
+-- run
+
+-- === UNIQUE with PK-change UPDATE ===
+
+CREATE TABLE t_uc_pkchg (id INTEGER PRIMARY KEY, code TEXT UNIQUE);
+INSERT INTO t_uc_pkchg VALUES (1, 'aaa');
+INSERT INTO t_uc_pkchg VALUES (2, 'bbb');
+-- run
+
+-- PK-change update that also conflicts on UNIQUE should fail
+UPDATE t_uc_pkchg SET id = 3, code = 'aaa' WHERE id = 2;
+-- error: UNIQUE constraint failed
+
+-- Old row should be preserved after failed PK-change update
+SELECT * FROM t_uc_pkchg ORDER BY id;
+→ [{"id":1,"code":"aaa"},{"id":2,"code":"bbb"}]
+
+-- PK-change update without UNIQUE conflict should succeed
+UPDATE t_uc_pkchg SET id = 3, code = 'ccc' WHERE id = 2;
+-- run
+
+SELECT * FROM t_uc_pkchg ORDER BY id;
+→ [{"id":1,"code":"aaa"},{"id":3,"code":"ccc"}]
+
+DROP TABLE t_uc_pkchg;
+-- run

package/test/logic/102.0.1-schema-catalog-indexed-table.sqllogic

@@ -0,0 +1,32 @@
+-- 102.0.1-schema-catalog-indexed-table.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 102-schema-catalog-edge-cases: that file's DDL round-trips,
+-- multi-schema search-path handling, table_info(), views, assertions and window
+-- coverage need no index DDL. This one section round-trips a table that carries
+-- secondary indexes, so it moves here rather than costing a backend without
+-- first-class CREATE INDEX the whole catalog file.
+--
+-- Subject: a table created with two secondary indexes stays queryable through the
+-- indexed columns, and both indexes drop cleanly.
+
+-- ===================================
+-- Table with indexes
+-- ===================================
+
+CREATE TABLE rt_indexed (id INTEGER PRIMARY KEY, name TEXT, category TEXT);
+CREATE INDEX idx_name ON rt_indexed (name);
+CREATE INDEX idx_cat ON rt_indexed (category);
+INSERT INTO rt_indexed VALUES (1, 'Alice', 'A'), (2, 'Bob', 'B');
+
+-- Verify indexes are used (data accessible via indexed columns)
+SELECT id FROM rt_indexed WHERE name = 'Alice';
+→ [{"id": 1}]
+
+SELECT id FROM rt_indexed WHERE category = 'B';
+→ [{"id": 2}]
+
+DROP INDEX idx_name;
+DROP INDEX idx_cat;
+DROP TABLE rt_indexed;

package/test/logic/102.1-unique-edge-cases.sqllogic

@@ -0,0 +1,111 @@
+-- adapted from SQLite test/unique.test, test/unique2.test
+-- UNIQUE constraint scenarios beyond 102-unique-constraints.sqllogic.
+
+-- ===================================
+-- 1. COLLATE with the LOWERCASE spelling `nocase` is NORMALIZED at DDL.
+--    SQLite treats collation names case-insensitively; Quereus normalizes the
+--    requested name to its canonical uppercase form in columnDefToSchema and
+--    validates against TEXT_TYPE.supportedCollations = ['BINARY','NOCASE','RTRIM']
+--    case-insensitively, so lowercase `nocase` is equivalent to `NOCASE`. A
+--    `collate nocase unique` column is therefore accepted and enforces
+--    case-insensitively (see unique-constraint-honors-column-collation /
+--    102.2-unique-collation.sqllogic). An UNKNOWN collation is still rejected,
+--    now with explicit "Unknown collation" wording (pinned below).
+-- ===================================
+
+create table t_uci (id integer primary key, email text collate nocase unique);
+insert into t_uci values (1, 'abc');
+
+-- the lowercase `nocase` spelling normalizes to NOCASE, so a case-variant
+-- duplicate is a UNIQUE violation under case-insensitive comparison
+insert into t_uci values (2, 'ABC');
+-- error: UNIQUE constraint failed: t_uci (email)
+
+select count(*) as n from t_uci;
+→ [{"n":1}]
+
+-- a value that is NOT NOCASE-equal still inserts
+insert into t_uci values (3, 'abd');
+select id, email from t_uci order by id;
+→ [{"id":1,"email":"abc"},{"id":3,"email":"abd"}]
+
+drop table t_uci;
+
+-- composite UNIQUE with the lowercase `nocase` spelling on a TEXT member is
+-- likewise accepted; the `a` member folds case under the normalized NOCASE
+create table t_uci2 (
+	id integer primary key,
+	a text collate nocase,
+	b text,
+	unique (a, b)
+);
+insert into t_uci2 values (1, 'abc', 'x');
+
+-- 'a' matches case-insensitively and 'b' matches under BINARY -> composite conflict
+insert into t_uci2 values (2, 'ABC', 'x');
+-- error: UNIQUE constraint failed: t_uci2
+
+select count(*) as n from t_uci2;
+→ [{"n":1}]
+
+-- a genuinely distinct 'a' still inserts (proves no over-matching)
+insert into t_uci2 values (3, 'xyz', 'x');
+select count(*) as n from t_uci2;
+→ [{"n":2}]
+
+drop table t_uci2;
+
+-- an UNKNOWN collation name is still rejected at DDL, now with explicit wording
+create table t_ucbad (id integer primary key, x text collate frobnicate);
+-- error: Unknown collation
+
+drop table if exists t_ucbad;
+
+-- ===================================
+-- 2. UNIQUE constraint error message identifies the violated column
+-- ===================================
+
+create table t_ue (id integer primary key, email text unique, code text unique);
+insert into t_ue values (1, 'a@x', 'AAA');
+
+-- conflict on email reports email
+insert into t_ue values (2, 'a@x', 'BBB');
+-- error: t_ue (email)
+
+-- conflict on code reports code
+insert into t_ue values (3, 'b@x', 'AAA');
+-- error: t_ue (code)
+
+drop table t_ue;
+
+-- composite UNIQUE error names the offending column(s)
+create table t_uec (id integer primary key, a text, b text, unique (a, b));
+insert into t_uec values (1, 'x', 'y');
+
+insert into t_uec values (2, 'x', 'y');
+-- error: t_uec
+
+drop table t_uec;
+
+-- ===================================
+-- 3. CREATE UNIQUE INDEX rejected when data already has duplicates
+-- ===================================
+-- Lives in 102.1.1-unique-index-creation-edge-cases: adding a UNIQUE after rows
+-- exist requires a standalone `create unique index`.
+
+-- ===================================
+-- 4. PRIMARY KEY / UNIQUE referencing non-existent column rejected at DDL
+-- ===================================
+
+create table u2_bad1 (a integer not null, b integer not null, primary key (nope));
+-- error:
+
+drop table if exists u2_bad1;
+
+create table u2_bad2 (id integer primary key, a integer not null, unique (missing));
+-- error:
+
+drop table if exists u2_bad2;
+
+-- The CREATE UNIQUE INDEX form of the same rejection lives in
+-- 102.1.1-unique-index-creation-edge-cases § 2.

package/test/logic/102.1.1-unique-index-creation-edge-cases.sqllogic

@@ -0,0 +1,75 @@
+-- 102.1.1-unique-index-creation-edge-cases.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 102.1-unique-edge-cases: the rest of that file establishes UNIQUE
+-- through inline or table-level constraints (collation normalization, duplicate
+-- rejection, missing-column DDL errors) and needs no index DDL. These sections build
+-- the constraint with a standalone `create unique index` instead, which is the only
+-- way to add one AFTER rows exist — so they move here rather than making the whole
+-- UNIQUE edge-case file unrunnable on a backend without first-class CREATE INDEX.
+--
+-- Subject: post-hoc CREATE UNIQUE INDEX — rejected over already-duplicated data,
+-- accepted after dedup and then enforcing, NULL-tolerant on nullable columns, and
+-- rejected outright when it names a column that does not exist.
+
+-- ===================================
+-- 1. CREATE UNIQUE INDEX rejected when data already has duplicates
+-- ===================================
+
+create table u2_a (k text primary key, x text not null);
+insert into u2_a values ('r1', 'dup'), ('r2', 'dup');
+
+create unique index u2_a_x on u2_a(x);
+-- error: UNIQUE
+
+-- after dedup, the index creates fine and rejects new duplicates
+delete from u2_a where k = 'r2';
+
+create unique index u2_a_x on u2_a(x);
+
+insert into u2_a values ('r3', 'dup');
+-- error: UNIQUE
+
+drop table u2_a;
+
+-- post-hoc CREATE UNIQUE INDEX on already-unique data subsequently rejects
+-- inserts that would violate the new unique constraint. Use `-- run` markers
+-- to run each step as its own implicit transaction; otherwise the CREATE
+-- UNIQUE INDEX would land in the same implicit transaction as the prior
+-- INSERTs, whose rows live in an uncommitted layer that the index's seed
+-- scan does not see (a known schema-change-mid-transaction limitation).
+create table u2_b (k integer primary key, x text not null);
+-- run
+insert into u2_b values (1, 'a'), (2, 'b');
+-- run
+create unique index u2_b_x on u2_b(x);
+-- run
+
+insert into u2_b values (3, 'a');
+-- error: UNIQUE
+
+drop table u2_b;
+
+-- nullable indexed columns: multiple NULL allowed
+create table u2_c (k integer primary key, y text null, z text null);
+insert into u2_c values (1, null, null), (2, null, null);
+
+create unique index u2_c_yz on u2_c(y, z);
+
+select count(*) as cnt from u2_c;
+→ [{"cnt":2}]
+
+drop table u2_c;
+
+-- ===================================
+-- 2. CREATE UNIQUE INDEX referencing a non-existent column rejected at DDL
+-- ===================================
+-- (the PRIMARY KEY / table-level UNIQUE forms of the same rejection stay in
+-- 102.1-unique-edge-cases § 4)
+
+create table u2_bad3 (id integer primary key, b integer not null);
+create unique index u2_bad3_idx on u2_bad3(no_such_col);
+-- error: not found
+
+drop table u2_bad3;

package/test/logic/102.2-unique-collation.sqllogic

@@ -0,0 +1,181 @@
+-- 102.2-unique-collation.sqllogic — a UNIQUE constraint over a column declared
+-- with a non-binary collation (e.g. `text collate NOCASE`) must enforce under that
+-- collation, not BINARY (unique-constraint-honors-column-collation). The auto-built
+-- UNIQUE index carries the column's declared collation, and every conflict validator
+-- (auto-index path, cold scan, and the row-time covering-MV path) re-compares with the
+-- column collation. Uses the canonical UPPERCASE spelling `NOCASE` / `RTRIM` — the
+-- lowercase spelling is rejected at DDL by a separate collation-name case-sensitivity
+-- quirk documented in 102.1-unique-edge-cases.sqllogic.
+--
+-- Runs under BOTH the memory module (`yarn test`) and the store module
+-- (`yarn test:store`); §4 additionally exercises the MV-backed enforcement path on
+-- each module, using a non-derived NOCASE column through a row-time covering MV.
+--
+-- Every section here declares its UNIQUE inline or table-level, so the enforcement
+-- collation is always the column's. The counterpart shapes — where the collation
+-- comes from an explicit `create unique index … collate …` instead — live in
+-- 102.2.1-unique-collation-index-derived (former §§9-13), split out because they
+-- need standalone index DDL.
+
+-- ===================================
+-- 1. Table-level `unique (x)` over a NOCASE column — auto-index enforcement.
+-- ===================================
+
+create table ta (id integer primary key, x text collate NOCASE, unique (x));
+insert into ta values (1, 'abc');
+
+-- a case-insensitive duplicate is a UNIQUE violation under NOCASE (was silently
+-- accepted as a distinct value under the old BINARY enforcement)
+insert into ta values (2, 'ABC');
+-- error: UNIQUE constraint failed: ta (x)
+
+select count(*) as n from ta;
+→ [{"n":1}]
+
+-- a value that is NOT NOCASE-equal still inserts (guard against over-matching)
+insert into ta values (3, 'abd');
+select id, x from ta order by id;
+→ [{"id":1,"x":"abc"},{"id":3,"x":"abd"}]
+
+-- ===================================
+-- 2. Column-level inline `x text collate NOCASE unique` — same enforcement.
+-- ===================================
+
+create table tb (id integer primary key, x text collate NOCASE unique);
+insert into tb values (1, 'abc');
+
+insert into tb values (2, 'ABC');
+-- error: UNIQUE constraint failed: tb (x)
+
+select count(*) as n from tb;
+→ [{"n":1}]
+
+-- ===================================
+-- 3. OR IGNORE / OR REPLACE interplay on a NOCASE duplicate.
+-- ===================================
+
+create table tc (id integer primary key, x text collate NOCASE unique);
+insert into tc values (1, 'abc');
+
+-- OR IGNORE: the case-insensitive duplicate is silently skipped
+insert or ignore into tc values (2, 'ABC');
+select id, x from tc order by id;
+→ [{"id":1,"x":"abc"}]
+
+-- OR REPLACE: the case-insensitive duplicate (id=1) is evicted, the new row lands
+insert or replace into tc values (3, 'ABC');
+select id, x from tc order by id;
+→ [{"id":3,"x":"ABC"}]
+
+-- ===================================
+-- 4. Row-time covering MV over a NOCASE column — MV-backed enforcement path.
+--    `findIndexForConstraint` prefers the covering MV over the auto-index, so this
+--    drives `checkUniqueViaMaterializedView` (memory) / `findUniqueConflictViaCoveringMv`
+--    (store). Mirrors 54-covering-mv-enforcement.sqllogic.
+-- ===================================
+
+create table tm (id integer primary key, x text collate NOCASE, unique (x));
+create materialized view tm_ix as select x, id from tm order by x;
+insert into tm values (1, 'abc');
+
+-- default ABORT through the covering MV: a NOCASE duplicate with a different PK is rejected
+insert into tm values (2, 'ABC');
+-- error: UNIQUE constraint failed: tm (x)
+
+select count(*) as n from tm;
+→ [{"n":1}]
+
+-- OR REPLACE through the covering MV: id=1 evicted, id=10 lands
+insert or replace into tm values (10, 'ABC');
+select id, x from tm order by id;
+→ [{"id":10,"x":"ABC"}]
+
+-- a non-NOCASE-equal value still inserts through the covering path
+insert into tm values (11, 'abd');
+select id, x from tm order by id;
+→ [{"id":10,"x":"ABC"},{"id":11,"x":"abd"}]
+
+-- ===================================
+-- 5. Generality with a second collation: `collate RTRIM` ignores trailing spaces.
+-- ===================================
+
+create table tr (id integer primary key, x text collate RTRIM, unique (x));
+insert into tr values (1, 'abc');
+
+-- a trailing-space-only variant collides under RTRIM
+insert into tr values (2, 'abc   ');
+-- error: UNIQUE constraint failed: tr (x)
+
+select count(*) as n from tr;
+→ [{"n":1}]
+
+-- a genuinely different value still inserts
+insert into tr values (3, 'abcd');
+select id, x from tr order by id;
+→ [{"id":1,"x":"abc"},{"id":3,"x":"abcd"}]
+
+-- ===================================
+-- 6. Composite UNIQUE with a mix of NOCASE + BINARY members — each member is
+--    compared under its OWN declared collation (per-column threading), not a
+--    single table-wide collation. The NOCASE member folds case; the BINARY
+--    member does not.
+-- ===================================
+
+create table tcomp (id integer primary key, a text collate NOCASE, b text collate BINARY, unique (a, b));
+insert into tcomp values (1, 'abc', 'xyz');
+
+-- both members match under their own collations (a: NOCASE-equal, b: BINARY-equal) → conflict
+insert into tcomp values (2, 'ABC', 'xyz');
+-- error: UNIQUE constraint failed: tcomp
+
+select count(*) as n from tcomp;
+→ [{"n":1}]
+
+-- a matches under NOCASE but b differs under BINARY ('XYZ' != 'xyz'), so the composite
+-- key is distinct and the row inserts — proves the BINARY member is NOT case-folded
+insert into tcomp values (3, 'ABC', 'XYZ');
+select id, a, b from tcomp order by id;
+→ [{"id":1,"a":"abc","b":"xyz"},{"id":3,"a":"ABC","b":"XYZ"}]
+
+-- ===================================
+-- 7. UPDATE onto a NOCASE-equal value is rejected (the conflict validators back
+--    UPDATE as well as INSERT). Guards the UPDATE path, not just INSERT.
+-- ===================================
+
+create table tu (id integer primary key, x text collate NOCASE, unique (x));
+insert into tu values (1, 'abc');
+insert into tu values (2, 'def');
+
+-- moving id=2's value onto a NOCASE-equal of id=1's value collides
+update tu set x = 'ABC' where id = 2;
+-- error: UNIQUE constraint failed: tu
+
+-- the aborted UPDATE left both rows unchanged
+select id, x from tu order by id;
+→ [{"id":1,"x":"abc"},{"id":2,"x":"def"}]
+
+-- updating onto a genuinely distinct value still succeeds
+update tu set x = 'xyz' where id = 2;
+select id, x from tu order by id;
+→ [{"id":1,"x":"abc"},{"id":2,"x":"xyz"}]
+
+-- ===================================
+-- 8. The LOWERCASE collation spelling `collate nocase` normalizes to NOCASE and
+--    enforces identically to the uppercase form (DDL case-insensitivity fix).
+-- ===================================
+
+create table tl (id integer primary key, x text collate nocase unique);
+insert into tl values (1, 'abc');
+
+-- a case-variant duplicate collides under the normalized NOCASE collation
+insert into tl values (2, 'ABC');
+-- error: UNIQUE constraint failed: tl (x)
+
+select count(*) as n from tl;
+→ [{"n":1}]
+
+-- a non-NOCASE-equal value still inserts
+insert into tl values (3, 'abd');
+select id, x from tl order by id;
+→ [{"id":1,"x":"abc"},{"id":3,"x":"abd"}]
+