@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/102.2.1-unique-collation-index-derived.sqllogic

@@ -0,0 +1,305 @@
+-- 102.2.1-unique-collation-index-derived.sqllogic — UNIQUE whose collation comes from a
+-- standalone `create unique index`, not from the column declaration.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 102.2-unique-collation: §§1-8 there prove the same collation ground
+-- (auto-index enforcement, OR IGNORE/OR REPLACE, covering-MV path, RTRIM, composite
+-- members, UPDATE, lowercase spelling) using only inline / table-level `unique`, and
+-- are a complete self-sufficient subset. Everything below needs an explicit
+-- `create unique index … collate …`, which is the only way to give a UNIQUE a
+-- collation that differs from its column's.
+--
+-- Runs under BOTH the memory module (`yarn test`) and the store module
+-- (`yarn test:store`). §1 (was §9) exercises the index-derived shapes (finer / coarser /
+-- plain index) through the plain per-scan / auto-index path. §2 (was §10) reruns them
+-- through a row-time covering MV, where the collation eligibility gate
+-- (`covering-mv-index-derived-unique-collation`) keeps an MV only when the index
+-- collation is coarser-or-equal to the declared column collation per column. §3 (was §11)
+-- covers two UNIQUE indexes over the SAME column-set with differing collations: each
+-- derived constraint enforces under ITS OWN index's collation in BOTH creation orders
+-- (`memory-multi-index-unique-collation-resolution`). §4 (was §12) covers a NON-derived
+-- (table-level / column) UNIQUE coexisting with a FINER same-column-set
+-- `create unique index`: the non-derived UNIQUE enforces under its DECLARED collation
+-- in BOTH creation orders, the user's finer index keeps enforcing its own uniqueness,
+-- and dropping the non-derived constraint leaves the user index intact
+-- (`memory-nonderived-unique-reused-finer-index-under-enforcement`). §5 (was §13) covers
+-- conflict resolution (OR REPLACE / OR IGNORE) over those two coexisting structures:
+-- a conflict on one is not a false conflict on the other, and OR REPLACE evicts
+-- exactly the row the conflicting structure identifies.
+--
+-- Section numbers below keep their original 9-13 labels so cross-references from
+-- 102.2 and from the source tickets still resolve.
+
+-- ===================================
+-- 9. Index-derived UNIQUE enforces under the INDEX's per-column collation, not
+--    the column's declared collation. A `create unique index … (col collate x)`
+--    carries its own comparator; both modules enforce through it (memory's
+--    checkUniqueViaIndex / the store's findUniqueConflict, both now resolving the
+--    index per-column collation). Run through the plain per-scan / auto-index
+--    path (no covering MV), where memory and store provably agree.
+--    (store-index-derived-unique-honors-index-collation.)
+-- ===================================
+
+-- 9a. FINER index (BINARY) over a NOCASE column ADMITS both case-variants — the
+--     NOCASE column would unify 'Bob'/'bob' but the BINARY index keeps them apart.
+create table fai (id integer primary key, b text collate NOCASE);
+create unique index fai_b on fai (b collate BINARY);
+insert into fai values (1, 'Bob');
+insert into fai values (2, 'bob');
+select id, b from fai order by id;
+→ [{"id":1,"b":"Bob"},{"id":2,"b":"bob"}]
+
+-- a genuine BINARY duplicate is still rejected (guard against under-matching)
+insert into fai values (3, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from fai;
+→ [{"n":2}]
+
+-- 9b. COARSER index (NOCASE) over a BINARY column UNIFIES case-variants — the
+--     BINARY column would keep 'Bob'/'BOB' distinct but the NOCASE index folds them.
+create table cbi (id integer primary key, b text);
+create unique index cbi_b on cbi (b collate NOCASE);
+insert into cbi values (1, 'Bob');
+insert into cbi values (2, 'BOB');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from cbi;
+→ [{"n":1}]
+
+-- a genuinely different value still inserts
+insert into cbi values (3, 'Carol');
+select id, b from cbi order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"}]
+
+-- 9c. A plain `create unique index` (no per-column COLLATE) falls back to the
+--     column's declared collation — a NOCASE column's index still folds case.
+create table pgi (id integer primary key, b text collate NOCASE);
+create unique index pgi_b on pgi (b);
+insert into pgi values (1, 'Bob');
+insert into pgi values (2, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from pgi;
+→ [{"n":1}]
+
+-- ===================================
+-- 10. Index-derived UNIQUE through a row-time COVERING MV. Parallels §9's per-scan
+--     shapes but with a covering MV linked, so the collation eligibility gate decides
+--     whether enforcement routes through the MV (BINARY-floor / equal collation) or
+--     falls back to the per-scan / auto-index path (finer/incomparable index). Both
+--     paths honor the INDEX per-column collation, so memory and store agree on each
+--     module (covering-mv-index-derived-unique-collation).
+-- ===================================
+
+-- 10a. FINER index (BINARY) over a NOCASE column + covering MV → eligible (I=BINARY
+--      floor). The candidate set is a superset; re-validation under BINARY admits both
+--      case-variants 'Bob'/'bob'. A genuine BINARY duplicate is still rejected.
+create table fam (id integer primary key, b text collate NOCASE);
+create unique index fam_b on fam (b collate BINARY);
+create materialized view fam_mv as select b, id from fam order by b;
+insert into fam values (1, 'Bob');
+insert into fam values (2, 'bob');
+select id, b from fam order by id;
+→ [{"id":1,"b":"Bob"},{"id":2,"b":"bob"}]
+
+insert into fam values (3, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from fam;
+→ [{"n":2}]
+
+-- 10b. COARSER index (NOCASE) over a BINARY column + covering MV → declined (I=NOCASE,
+--      D=BINARY). Enforcement falls back to the per-scan / auto-index path under the
+--      index NOCASE, so 'BOB' after 'Bob' is rejected (the silent miss the gate closes).
+create table cbm (id integer primary key, b text);
+create unique index cbm_b on cbm (b collate NOCASE);
+create materialized view cbm_mv as select b, id from cbm order by b;
+insert into cbm values (1, 'Bob');
+insert into cbm values (2, 'BOB');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from cbm;
+→ [{"n":1}]
+
+-- a genuinely different value still inserts through the per-scan path
+insert into cbm values (3, 'Carol');
+select id, b from cbm order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"}]
+
+-- 10c. PLAIN index (no per-column COLLATE) over a NOCASE column + covering MV →
+--      eligible (I falls back to D=NOCASE ⇒ equal). Unchanged NOCASE folding (mirrors §4).
+create table pgm (id integer primary key, b text collate NOCASE);
+create unique index pgm_b on pgm (b);
+create materialized view pgm_mv as select b, id from pgm order by b;
+insert into pgm values (1, 'Bob');
+insert into pgm values (2, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from pgm;
+→ [{"n":1}]
+
+-- a non-NOCASE-equal value still inserts through the covering path
+insert into pgm values (3, 'abd');
+select id, b from pgm order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"abd"}]
+
+-- ===================================
+-- 11. TWO UNIQUE indexes over the SAME column-set with DIFFERING collations. Each
+--     index-derived UNIQUE must enforce under ITS OWN index's collation, regardless
+--     of the order the indexes were created in. memory's findIndexForConstraint now
+--     resolves the enforcing index BY NAME (uc.derivedFromIndex), not the FIRST
+--     same-column-set index, so the coarser (NOCASE) UNIQUE rejects a case-variant
+--     duplicate in BOTH creation orders while the finer (BINARY) UNIQUE keeps
+--     genuine byte-distinct values apart. On main the BINARY-first order silently
+--     ADMITTED the NOCASE duplicate (the order-sensitive under-enforcement bug,
+--     memory-multi-index-unique-collation-resolution); store already rejected both.
+-- ===================================
+
+-- 11a. BINARY index created FIRST, then NOCASE. The NOCASE UNIQUE still catches a
+--      case-variant duplicate — index order no longer decides the enforcing collation.
+create table mbf (id integer primary key, b text collate NOCASE);
+create unique index mbf_binary on mbf (b collate BINARY);
+create unique index mbf_nocase on mbf (b collate NOCASE);
+insert into mbf values (1, 'Bob');
+
+-- 'bob' is BINARY-distinct from 'Bob' but NOCASE-equal → the NOCASE UNIQUE rejects it
+insert into mbf values (2, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from mbf;
+→ [{"n":1}]
+
+-- a genuinely distinct value (neither NOCASE- nor BINARY-equal) still inserts — the
+-- finer BINARY index keys byte-distinct values apart without raising a false conflict
+insert into mbf values (3, 'Carol');
+select id, b from mbf order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"}]
+
+-- 11b. Reverse creation order: NOCASE FIRST, then BINARY. Same enforcement — the
+--      NOCASE UNIQUE rejects the case-variant regardless of index order.
+create table mnf (id integer primary key, b text collate NOCASE);
+create unique index mnf_nocase on mnf (b collate NOCASE);
+create unique index mnf_binary on mnf (b collate BINARY);
+insert into mnf values (1, 'Bob');
+
+insert into mnf values (2, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from mnf;
+→ [{"n":1}]
+
+insert into mnf values (3, 'Carol');
+select id, b from mnf order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"}]
+
+-- ===================================
+-- 12. A NON-derived (table-level / column) UNIQUE coexisting with a FINER
+--     same-column-set `create unique index`. The non-derived UNIQUE enforces under
+--     its DECLARED column collation (NOCASE) regardless of DDL order — the memory
+--     module no longer reuses or resolves onto the finer (BINARY) user index, which
+--     would silently ADMIT a NOCASE duplicate. The user's BINARY index keeps
+--     enforcing its OWN (byte-exact) uniqueness, and dropping the non-derived
+--     constraint leaves that index intact. On main the index-first order under-enforced
+--     (count went to 2); store already rejected both orders.
+--     (memory-nonderived-unique-reused-finer-index-under-enforcement.)
+-- ===================================
+
+-- 12a. INDEX created FIRST, then `alter table … add constraint uq unique (b)` over a
+--      NOCASE column. The NOCASE UNIQUE rejects a case-variant duplicate that the
+--      finer BINARY index alone would have admitted — the bug this fix closes.
+create table mif (id integer primary key, b text collate NOCASE);
+create unique index mif_binary on mif (b collate BINARY);
+alter table mif add constraint uq unique (b);
+insert into mif values (1, 'Bob');
+
+-- 'bob' is BINARY-distinct from 'Bob' but NOCASE-equal → the non-derived NOCASE UNIQUE rejects it
+insert into mif values (2, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from mif;
+→ [{"n":1}]
+
+-- a genuinely distinct value (neither NOCASE- nor BINARY-equal) still inserts (guard against over-matching)
+insert into mif values (3, 'Carol');
+select id, b from mif order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"}]
+
+-- 12b. CONSTRAINT created FIRST (table-level `unique (b)`), THEN the finer index —
+--      order-independence. Same NOCASE enforcement.
+create table mcf (id integer primary key, b text collate NOCASE, unique (b));
+create unique index mcf_binary on mcf (b collate BINARY);
+insert into mcf values (1, 'Bob');
+
+insert into mcf values (2, 'bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from mcf;
+→ [{"n":1}]
+
+insert into mcf values (3, 'Carol');
+select id, b from mcf order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"}]
+
+-- 12c. Lifecycle: dropping the non-derived NOCASE UNIQUE leaves the user's BINARY
+--      index (`mif_binary`) enforcing its own uniqueness. A NOCASE-variant is now
+--      ADMITTED (only BINARY enforces, keeping case-variants apart) while a genuine
+--      byte-exact duplicate is still rejected — proof the user index survived the drop.
+alter table mif drop constraint uq;
+
+-- NOCASE folding gone: 'BOB' is BINARY-distinct from existing 'Bob'/'Carol' → admitted
+insert into mif values (4, 'BOB');
+select id, b from mif order by id;
+→ [{"id":1,"b":"Bob"},{"id":3,"b":"Carol"},{"id":4,"b":"BOB"}]
+
+-- but a byte-exact duplicate of 'Bob' is still rejected by the surviving BINARY index
+insert into mif values (5, 'Bob');
+-- error: UNIQUE constraint failed
+
+select count(*) as n from mif;
+→ [{"n":3}]
+
+-- ===================================
+-- 13. Conflict resolution (OR REPLACE / OR IGNORE) with the TWO coexisting unique
+--     structures the §12 fix produces: a NOCASE non-derived UNIQUE (`uq`) and a
+--     FINER BINARY user index (`ixb`). The two enforce DIFFERENT equivalences, so a
+--     conflict on one must not be a false conflict on the other, and OR REPLACE must
+--     evict exactly the row the conflicting structure identifies. Runs under memory
+--     AND store (cross-module conformance with SQLite).
+--     (memory-nonderived-unique-reused-finer-index-under-enforcement, review.)
+-- ===================================
+
+create table p (id integer primary key, b text collate nocase);
+create unique index ixb on p (b collate binary);
+alter table p add constraint uq unique (b);
+insert into p values (1, 'Bob');
+
+-- OR REPLACE on 'bob': NOCASE-dup of 'Bob' but BINARY-distinct → the NOCASE UNIQUE
+-- drives the conflict and evicts id=1; the BINARY index raises no false conflict.
+insert or replace into p values (2, 'bob');
+select id, b from p order by id;
+→ [{"id":2,"b":"bob"}]
+
+-- OR IGNORE on 'BOB': NOCASE-dup of the surviving 'bob' → ignored, table unchanged.
+insert or ignore into p values (3, 'BOB');
+select id, b from p order by id;
+→ [{"id":2,"b":"bob"}]
+
+-- OR REPLACE byte-exact dup of 'bob' → BOTH structures conflict on the SAME row id=2;
+-- it is evicted once and the new row inserted (no double-evict error).
+insert or replace into p values (4, 'bob');
+select id, b from p order by id;
+→ [{"id":4,"b":"bob"}]
+
+-- OR REPLACE where the NOCASE structure conflicts on one row while a DIFFERENT row
+-- stays clear of both: 'Cat' NOCASE-matches 'cat' (id=1); 'DOG' is BINARY- and
+-- NOCASE-distinct → only id=1 is evicted, id=2 survives.
+create table q (id integer primary key, b text collate nocase);
+create unique index qixb on q (b collate binary);
+alter table q add constraint uq2 unique (b);
+insert into q values (1, 'cat');
+insert into q values (2, 'DOG');
+insert or replace into q values (3, 'Cat');
+select id, b from q order by id;
+→ [{"id":2,"b":"DOG"},{"id":3,"b":"Cat"}]

package/test/logic/103-database-options-edge-cases.sqllogic

@@ -0,0 +1,108 @@
+-- database-options-edge-cases.sqllogic - Pragma edge cases and option handling
+
+-- ===================================
+-- PRAGMA default_vtab_module
+-- ===================================
+
+-- Default should be 'memory'
+PRAGMA default_vtab_module;
+→ [{"name": "default_vtab_module", "value": "memory"}]
+
+-- Set to 'memory' explicitly (same value, should be no-op)
+PRAGMA default_vtab_module = 'memory';
+-- run
+
+PRAGMA default_vtab_module;
+→ [{"name": "default_vtab_module", "value": "memory"}]
+
+-- ===================================
+-- PRAGMA schema_path basics
+-- ===================================
+
+-- Default should be 'main'
+PRAGMA schema_path;
+→ [{"name": "schema_path", "value": "main"}]
+
+-- Set and read back
+PRAGMA schema_path = 'main,temp';
+
+PRAGMA schema_path;
+→ [{"name": "schema_path", "value": "main,temp"}]
+
+-- Reset
+PRAGMA schema_path = 'main';
+-- run
+
+-- ===================================
+-- Invalid pragma names
+-- ===================================
+
+PRAGMA nonexistent_pragma;
+-- error: Unknown pragma
+
+PRAGMA nonexistent_pragma = 'value';
+-- error: Unknown pragma
+
+-- ===================================
+-- Boolean pragma values (various forms)
+-- ===================================
+
+-- Create a table to use for testing
+CREATE TABLE pragma_test (id INTEGER PRIMARY KEY, val TEXT);
+
+-- Test boolean conversion forms via PRAGMA (using known boolean pragmas)
+-- The exact boolean pragmas depend on what's registered, but we can test
+-- that the system handles queries correctly after pragma changes
+
+INSERT INTO pragma_test VALUES (1, 'test');
+
+SELECT * FROM pragma_test;
+→ [{"id": 1, "val": "test"}]
+
+DROP TABLE pragma_test;
+
+-- ===================================
+-- Multiple pragmas in sequence
+-- ===================================
+
+PRAGMA schema_path = 'main';
+PRAGMA default_vtab_module = 'memory';
+-- run
+
+PRAGMA schema_path;
+→ [{"name": "schema_path", "value": "main"}]
+
+PRAGMA default_vtab_module;
+→ [{"name": "default_vtab_module", "value": "memory"}]
+
+-- ===================================
+-- table_info on various table shapes
+-- ===================================
+
+-- Simple table
+CREATE TABLE pi_simple (id INTEGER PRIMARY KEY, name TEXT);
+
+SELECT name, type, pk FROM table_info('pi_simple') ORDER BY cid;
+→ [{"name": "id", "type": "INTEGER", "pk": 1}, {"name": "name", "type": "TEXT", "pk": 0}]
+
+DROP TABLE pi_simple;
+
+-- Table with many column types
+CREATE TABLE pi_types (
+	a INTEGER PRIMARY KEY,
+	b TEXT NOT NULL,
+	c REAL,
+	d BLOB
+);
+
+SELECT name, type, pk FROM table_info('pi_types') ORDER BY cid;
+→ [{"name": "a", "type": "INTEGER", "pk": 1}, {"name": "b", "type": "TEXT", "pk": 0}, {"name": "c", "type": "REAL", "pk": 0}, {"name": "d", "type": "BLOB", "pk": 0}]
+
+DROP TABLE pi_types;
+
+-- ===================================
+-- table_info on non-existent table should error
+-- ===================================
+
+SELECT * FROM table_info('does_not_exist');
+-- error: not found

package/test/logic/103.1-pragma-boolean-values.sqllogic

@@ -0,0 +1,126 @@
+-- pragma-boolean-values.sqllogic - PRAGMA boolean value bareword parsing
+--
+-- Regression coverage for the `on`/`off` bareword spellings of a boolean
+-- pragma value. `on` lexes as the JOIN keyword (TokenType.ON), while `off`
+-- is not a reserved word at all -- so `pragma foreign_keys = off` always
+-- parsed fine, but `pragma foreign_keys = on` used to throw a misleading
+-- "'ON' must follow a JOIN" parse error. The fix accepts any
+-- CONTEXTUAL_KEYWORDS-listed bareword (not just `on`) as a name/value item.
+
+-- Default is true
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": true}]
+
+-- ===================================
+-- off (never broken; regression guard)
+-- ===================================
+
+PRAGMA foreign_keys = off;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": false}]
+
+-- ===================================
+-- on (the bug: used to throw a JOIN parse error)
+-- ===================================
+
+PRAGMA foreign_keys = on;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": true}]
+
+-- ===================================
+-- Case-insensitivity
+-- ===================================
+
+PRAGMA foreign_keys = OFF;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": false}]
+
+PRAGMA foreign_keys = On;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": true}]
+
+-- ===================================
+-- Quoted string forms
+-- ===================================
+
+PRAGMA foreign_keys = 'off';
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": false}]
+
+PRAGMA foreign_keys = 'on';
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": true}]
+
+-- ===================================
+-- Numeric and TRUE/FALSE forms (regression guard)
+-- ===================================
+
+PRAGMA foreign_keys = 0;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": false}]
+
+PRAGMA foreign_keys = 1;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": true}]
+
+PRAGMA foreign_keys = false;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": false}]
+
+PRAGMA foreign_keys = true;
+-- run
+
+PRAGMA foreign_keys;
+→ [{"name": "foreign_keys", "value": true}]
+
+-- ===================================
+-- Another boolean pragma on the same grammar path
+-- ===================================
+
+PRAGMA runtime_fuse_scalars = off;
+-- run
+
+PRAGMA runtime_fuse_scalars;
+→ [{"name": "runtime_fuse_scalars", "value": false}]
+
+PRAGMA runtime_fuse_scalars = on;
+-- run
+
+PRAGMA runtime_fuse_scalars;
+→ [{"name": "runtime_fuse_scalars", "value": true}]
+
+-- ===================================
+-- Generality: any CONTEXTUAL_KEYWORDS bareword is a value, not just `on`.
+-- A string-typed pragma stores it verbatim (no boolean conversion involved).
+-- ===================================
+
+PRAGMA schema_path = key;
+-- run
+
+PRAGMA schema_path;
+→ [{"name": "schema_path", "value": "key"}]
+
+-- Reset
+PRAGMA schema_path = 'main';
+-- run
+
+PRAGMA schema_path;
+→ [{"name": "schema_path", "value": "main"}]