@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/43-transition-constraints.sqllogic

@@ -0,0 +1,341 @@
+-- transition-constraints.sqllogic - Testing transition constraints using committed.* pseudo-schema
+-- These tests verify that CHECK constraints and assertions can reference committed.*
+-- to express transition rules (comparing before/after state).
+
+-- ===================================
+-- CHECK constraint with committed subquery: auto-deferred
+-- ===================================
+
+CREATE TABLE accounts (
+  id INTEGER PRIMARY KEY,
+  balance INTEGER,
+  CONSTRAINT no_decrease CHECK (
+    balance >= coalesce((SELECT balance FROM committed.accounts ca WHERE ca.id = new.id), 0)
+  )
+) USING memory;
+
+-- Insert initial data (no committed counterpart → COALESCE to 0)
+INSERT INTO accounts VALUES (1, 100);
+INSERT INTO accounts VALUES (2, 200);
+COMMIT;
+
+-- Valid: increase balance
+BEGIN;
+UPDATE accounts SET balance = 150 WHERE id = 1;
+COMMIT;
+-- run
+
+SELECT balance FROM accounts WHERE id = 1;
+→ [{ "balance": 150 }]
+
+-- Valid: balance stays the same
+BEGIN;
+UPDATE accounts SET balance = 150 WHERE id = 1;
+COMMIT;
+-- run
+
+-- Invalid: decrease balance → CHECK fires at commit
+BEGIN;
+UPDATE accounts SET balance = 50 WHERE id = 1;
+COMMIT;
+-- error: CHECK constraint failed: no_decrease
+
+-- Verify state unchanged
+SELECT balance FROM accounts WHERE id = 1;
+→ [{ "balance": 150 }]
+
+DROP TABLE accounts;
+-- run
+
+-- ===================================
+-- CHECK constraint: new rows pass (no committed counterpart)
+-- ===================================
+
+CREATE TABLE items (
+  id INTEGER PRIMARY KEY,
+  score INTEGER,
+  CONSTRAINT score_no_decrease CHECK (
+    score >= coalesce((SELECT score FROM committed.items ci WHERE ci.id = new.id), 0)
+  )
+) USING memory;
+
+-- New rows with positive score: OK (COALESCE to 0)
+INSERT INTO items VALUES (1, 10);
+INSERT INTO items VALUES (2, 20);
+COMMIT;
+
+SELECT score FROM items ORDER BY id;
+→ [{ "score": 10 }, { "score": 20 }]
+
+-- New row with zero score: OK (COALESCE to 0)
+INSERT INTO items VALUES (3, 0);
+COMMIT;
+-- run
+
+-- New row with negative score: fails (< 0 default)
+BEGIN;
+INSERT INTO items VALUES (4, -5);
+COMMIT;
+-- error: CHECK constraint failed: score_no_decrease
+
+SELECT count(*) FROM items;
+→ [{ "count(*)": 3 }]
+
+DROP TABLE items;
+-- run
+
+-- ===================================
+-- Assertion: count preservation (cardinality can only grow)
+-- ===================================
+
+CREATE TABLE entries (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO entries VALUES (1, 'a');
+INSERT INTO entries VALUES (2, 'b');
+COMMIT;
+
+CREATE ASSERTION no_shrink CHECK (
+  (SELECT count(*) FROM entries) >= (SELECT count(*) FROM committed.entries)
+);
+-- run
+
+-- Insert: count grows → OK
+BEGIN;
+INSERT INTO entries VALUES (3, 'c');
+COMMIT;
+-- run
+
+SELECT count(*) FROM entries;
+→ [{ "count(*)": 3 }]
+
+-- Delete: count shrinks → fails
+BEGIN;
+DELETE FROM entries WHERE id = 3;
+COMMIT;
+-- error: Integrity assertion failed: no_shrink
+
+-- Verify state unchanged
+SELECT count(*) FROM entries;
+→ [{ "count(*)": 3 }]
+
+DROP ASSERTION no_shrink;
+DROP TABLE entries;
+-- run
+
+-- ===================================
+-- Assertion: multiple committed refs in same expression
+-- ===================================
+
+CREATE TABLE balances (id INTEGER PRIMARY KEY, amount INTEGER);
+CREATE TABLE totals (id INTEGER PRIMARY KEY, total INTEGER);
+INSERT INTO balances VALUES (1, 100);
+INSERT INTO totals VALUES (1, 100);
+COMMIT;
+
+-- Assert both tables' counts can only increase
+CREATE ASSERTION multi_committed CHECK (
+  (SELECT count(*) FROM balances) >= (SELECT count(*) FROM committed.balances)
+  AND
+  (SELECT count(*) FROM totals) >= (SELECT count(*) FROM committed.totals)
+);
+-- run
+
+-- Valid: insert into both (count grows)
+BEGIN;
+INSERT INTO balances VALUES (2, 200);
+INSERT INTO totals VALUES (2, 200);
+COMMIT;
+-- run
+
+-- Invalid: delete from balances (count shrinks)
+BEGIN;
+DELETE FROM balances WHERE id = 2;
+COMMIT;
+-- error: Integrity assertion failed: multi_committed
+
+-- Invalid: delete from totals (count shrinks)
+BEGIN;
+DELETE FROM totals WHERE id = 2;
+COMMIT;
+-- error: Integrity assertion failed: multi_committed
+
+-- Verify state unchanged
+SELECT count(*) FROM balances;
+→ [{ "count(*)": 2 }]
+SELECT count(*) FROM totals;
+→ [{ "count(*)": 2 }]
+
+DROP ASSERTION multi_committed;
+DROP TABLE totals;
+DROP TABLE balances;
+-- run
+
+-- ===================================
+-- Assertion: deleted rows detection (exist in committed but not current)
+-- ===================================
+
+CREATE TABLE protected (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO protected VALUES (1, 'keep');
+INSERT INTO protected VALUES (2, 'keep');
+COMMIT;
+
+-- Assert no rows are deleted
+CREATE ASSERTION no_deletes CHECK (NOT EXISTS (
+  SELECT 1 FROM committed.protected cp
+  WHERE NOT EXISTS (SELECT 1 FROM protected p WHERE p.id = cp.id)
+));
+-- run
+
+-- Insert new row: OK (doesn't delete anything)
+BEGIN;
+INSERT INTO protected VALUES (3, 'new');
+COMMIT;
+-- run
+
+-- Update existing row: OK
+BEGIN;
+UPDATE protected SET val = 'updated' WHERE id = 1;
+COMMIT;
+-- run
+
+-- Delete a row: fails
+BEGIN;
+DELETE FROM protected WHERE id = 2;
+COMMIT;
+-- error: Integrity assertion failed: no_deletes
+
+-- Verify state unchanged
+SELECT count(*) FROM protected;
+→ [{ "count(*)": 3 }]
+
+DROP ASSERTION no_deletes;
+DROP TABLE protected;
+-- run
+
+-- ===================================
+-- CHECK constraint + assertion together with committed refs
+-- ===================================
+
+CREATE TABLE ledger (
+  id INTEGER PRIMARY KEY,
+  amount INTEGER,
+  CONSTRAINT amount_no_decrease CHECK (
+    amount >= coalesce((SELECT amount FROM committed.ledger cl WHERE cl.id = new.id), 0)
+  )
+) USING memory;
+
+INSERT INTO ledger VALUES (1, 50);
+INSERT INTO ledger VALUES (2, 100);
+COMMIT;
+
+-- Also add an assertion for count preservation
+CREATE ASSERTION ledger_no_deletes CHECK (
+  (SELECT count(*) FROM ledger) >= (SELECT count(*) FROM committed.ledger)
+);
+-- run
+
+-- Valid: increase individual amounts
+BEGIN;
+UPDATE ledger SET amount = 75 WHERE id = 1;
+COMMIT;
+-- run
+
+-- Invalid: decrease individual amount (CHECK catches it)
+BEGIN;
+UPDATE ledger SET amount = 10 WHERE id = 1;
+COMMIT;
+-- error: CHECK constraint failed: amount_no_decrease
+
+-- Verify state
+SELECT amount FROM ledger WHERE id = 1;
+→ [{ "amount": 75 }]
+
+DROP ASSERTION ledger_no_deletes;
+DROP TABLE ledger;
+-- run
+
+-- ===================================
+-- Deferred CHECK across tables with datetime coercion (GitHub #25)
+-- The deferred subquery compares new.* against an already-coerced stored row.
+-- A datetime column rewrites its value on parse, so the comparison must run
+-- coerced-vs-coerced or it spuriously fails.
+-- ===================================
+
+CREATE TABLE Parent (Id TEXT, TS datetime, PRIMARY KEY (Id, TS)) USING memory;
+CREATE TABLE Child (
+  Id TEXT PRIMARY KEY,
+  ParentTS datetime,
+  CONSTRAINT ParentExists CHECK (
+    EXISTS (SELECT 1 FROM Parent P WHERE P.TS = new.ParentTS)
+  )
+) USING memory;
+
+-- Parent.TS coerced from numeric literal to the datetime logical representation
+INSERT INTO Parent VALUES ('p1', 1700000000000);
+COMMIT;
+
+-- Positive: matching parent (numeric literal coerces to the same value) → OK
+BEGIN;
+INSERT INTO Child VALUES ('c1', 1700000000000);
+COMMIT;
+-- run
+
+SELECT count(*) FROM Child;
+→ [{ "count(*)": 1 }]
+
+-- Negative: no matching parent → deferred CHECK still fires at commit
+BEGIN;
+INSERT INTO Child VALUES ('c2', 1800000000000);
+COMMIT;
+-- error: CHECK constraint failed: ParentExists
+
+-- Verify the failed row did not land
+SELECT count(*) FROM Child;
+→ [{ "count(*)": 1 }]
+
+-- Alternate textual representation on both sides — Z-suffixed input now
+-- canonicalizes through the column-type parse, so this exercises that path.
+INSERT INTO Parent VALUES ('p2', '2023-11-14T22:13:20Z');
+COMMIT;
+
+BEGIN;
+INSERT INTO Child VALUES ('c3', '2023-11-14T22:13:20Z');
+COMMIT;
+-- run
+
+SELECT count(*) FROM Child;
+→ [{ "count(*)": 2 }]
+
+-- UPDATE shares the deferred-queue call site, so NEW is coerced there too.
+-- p3 stored from a numeric literal; the matching deferred-CHECK UPDATE below
+-- uses a textual representation of the same instant. Since datetime coercion
+-- is now canonical across input representations, the numeric-stored value
+-- and the textual NEW compare equal.
+INSERT INTO Parent VALUES ('p3', 1500000000000);
+COMMIT;
+
+BEGIN;
+UPDATE Child SET ParentTS = 1500000000000 WHERE Id = 'c1';
+COMMIT;
+-- run
+
+-- Textual-NEW vs numeric-stored UPDATE: 1600000000000 ms = 2020-09-13T12:26:40Z.
+INSERT INTO Parent VALUES ('p4', 1600000000000);
+COMMIT;
+
+BEGIN;
+UPDATE Child SET ParentTS = '2020-09-13T12:26:40Z' WHERE Id = 'c3';
+COMMIT;
+-- run
+
+-- Negative UPDATE: no matching parent → deferred CHECK still fires at commit
+BEGIN;
+UPDATE Child SET ParentTS = 1900000000000 WHERE Id = 'c1';
+COMMIT;
+-- error: CHECK constraint failed: ParentExists
+
+SELECT count(*) FROM Child;
+→ [{ "count(*)": 2 }]
+
+DROP TABLE Child;
+DROP TABLE Parent;
+-- run

package/test/logic/43.1-default-collation.sqllogic

@@ -0,0 +1,140 @@
+-- 43.1-default-collation.sqllogic - per-DB default_collation pragma.
+-- Sets the declared collation a column with NO explicit COLLATE resolves to.
+-- Defaults to BINARY (no behavior change). An explicit COLLATE always wins, and
+-- the default applies only to types that support the collation (text); non-text
+-- and empty-collation types (INTEGER/REAL/BLOB, JSON/temporal) fall back to BINARY.
+
+-- ===================================
+-- 0. Default is BINARY — out-of-box behavior unchanged.
+-- ===================================
+
+pragma default_collation;
+→ [{"name": "default_collation", "value": "BINARY"}]
+
+create table t_base (id integer primary key, name text);
+insert into t_base values (1, 'a');
+
+-- BINARY: a case-different literal does NOT match.
+select count(*) as n from t_base where name = 'A';
+→ [{"n":0}]
+
+select name, collation from table_info('t_base') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"BINARY"}]
+
+drop table t_base;
+
+-- ===================================
+-- 1. default_collation = NOCASE: an omitted-COLLATE text column resolves to NOCASE.
+-- ===================================
+
+pragma default_collation='nocase';
+pragma default_collation;
+→ [{"name": "default_collation", "value": "nocase"}]
+
+create table t_nc (id integer primary key, name text);
+insert into t_nc values (1, 'a');
+
+-- NOCASE: 'A' now matches the row inserted as 'a'.
+select count(*) as n from t_nc where name = 'A';
+→ [{"n":1}]
+
+-- table_info: id (INTEGER) falls back to BINARY; name (TEXT) is NOCASE.
+select name, collation from table_info('t_nc') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"NOCASE"}]
+
+drop table t_nc;
+
+-- ===================================
+-- 2. Non-text fallback: INTEGER / REAL / BLOB stay BINARY under a non-BINARY default.
+-- ===================================
+
+create table t_types (id integer primary key, amount real, payload blob, label text);
+select name, collation from table_info('t_types') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"amount","collation":"BINARY"},{"name":"payload","collation":"BINARY"},{"name":"label","collation":"NOCASE"}]
+
+drop table t_types;
+
+-- ===================================
+-- 3. Empty-collation types (JSON / temporal) stay BINARY under NOCASE.
+-- ===================================
+
+create table t_json (id integer primary key, doc json, created date);
+select name, collation from table_info('t_json') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"doc","collation":"BINARY"},{"name":"created","collation":"BINARY"}]
+
+drop table t_json;
+
+-- `any` declares no supported-collation list either, so it stays BINARY too.
+-- This matters since `ANY_TYPE.compare` began honoring its collation argument
+-- (ticket any-type-compare-honors-collation): an undecorated `any` column must
+-- keep comparing — and keying — BINARY, so only an explicit COLLATE moves it.
+create table t_any (id integer primary key, v any);
+select name, collation from table_info('t_any') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"v","collation":"BINARY"}]
+
+insert into t_any values (1, 'a');
+select count(*) as n from t_any where v = 'A';
+→ [{"n":0}]
+
+drop table t_any;
+
+-- ===================================
+-- 4. Explicit COLLATE always wins over the default.
+-- ===================================
+
+-- Explicit COLLATE BINARY under a NOCASE default stays BINARY (case-sensitive).
+create table t_expl (id integer primary key, name text collate binary);
+insert into t_expl values (1, 'a');
+select count(*) as n from t_expl where name = 'A';
+→ [{"n":0}]
+select name, collation from table_info('t_expl') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"BINARY"}]
+drop table t_expl;
+
+-- Explicit COLLATE RTRIM under a NOCASE default stays RTRIM.
+create table t_rt (id integer primary key, name text collate rtrim);
+select name, collation from table_info('t_rt') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"RTRIM"}]
+drop table t_rt;
+
+-- ===================================
+-- 5. ALTER TABLE ADD COLUMN honors default_collation (text → NOCASE, non-text → BINARY).
+-- ===================================
+-- Closes the CREATE-vs-ADD inconsistency: an ADD-COLUMN-ed text column gets NOCASE
+-- like a CREATE-d one, while a non-text added column falls back to BINARY
+-- (resolveDefaultCollation type-gate). Under test:store this also covers the store
+-- addColumn path and a persisted-DDL reopen round-trip.
+
+create table t_add (id integer primary key);
+alter table t_add add column name text;   -- text → NOCASE under the default
+alter table t_add add column qty integer; -- non-text → BINARY
+select name, collation from table_info('t_add') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"NOCASE"},{"name":"qty","collation":"BINARY"}]
+
+-- The added text column compares case-insensitively (NOCASE semantics).
+insert into t_add values (1, 'a', 10);
+select count(*) as n from t_add where name = 'A';
+→ [{"n":1}]
+
+drop table t_add;
+
+-- ===================================
+-- 6. Reset to BINARY restores out-of-box semantics.
+-- ===================================
+
+pragma default_collation='binary';
+pragma default_collation;
+→ [{"name": "default_collation", "value": "binary"}]
+
+create table t_reset (id integer primary key, name text);
+insert into t_reset values (1, 'a');
+select count(*) as n from t_reset where name = 'A';
+→ [{"n":0}]
+select name, collation from table_info('t_reset') order by cid;
+→ [{"name":"id","collation":"BINARY"},{"name":"name","collation":"BINARY"}]
+drop table t_reset;
+
+-- Note: rejection of an unknown default_collation (and value rollback) is covered by
+-- core-api-features.spec.ts — via the pragma path setOption errors are surfaced as the
+-- generic "Unknown pragma" (the real cause is chained), so the precise message is asserted
+-- at the API level instead.

package/test/logic/43.1-notnull-or-conflict.sqllogic

@@ -0,0 +1,79 @@
+-- adapted from SQLite test/notnull.test
+-- INSERT/UPDATE OR IGNORE / OR REPLACE / OR ABORT semantics on NOT NULL columns.
+-- Existing 102-unique-constraints covers the UNIQUE flavor; this covers NOT NULL.
+
+-- ===================================
+-- 1. INSERT OR IGNORE silently skips NOT NULL violations
+-- ===================================
+
+create table t_oi (id integer primary key, name text, score integer);
+insert into t_oi values (1, 'Alice', 10);
+
+-- NULL into NOT NULL column with OR IGNORE → row skipped, no error
+insert or ignore into t_oi values (2, null, 20);
+
+select count(*) as cnt from t_oi;
+→ [{"cnt":1}]
+
+insert or ignore into t_oi values (3, 'Bob', null);
+
+select count(*) as cnt from t_oi;
+→ [{"cnt":1}]
+
+-- valid row inserted
+insert or ignore into t_oi values (4, 'Carol', 40);
+
+select count(*) as cnt from t_oi;
+→ [{"cnt":2}]
+
+drop table t_oi;
+
+-- ===================================
+-- 2. INSERT OR REPLACE on NOT NULL with no DEFAULT → still errors
+-- ===================================
+
+create table t_or_no_def (id integer primary key, name text);
+
+insert or replace into t_or_no_def values (1, null);
+-- error: NOT NULL
+
+drop table t_or_no_def;
+
+-- ===================================
+-- 3. INSERT OR REPLACE on NOT NULL with DEFAULT — substitutes the default
+-- ===================================
+
+create table t_or_def (id integer primary key, name text default 'unknown');
+
+insert or replace into t_or_def values (1, null);
+
+select * from t_or_def where id = 1;
+→ [{"id":1,"name":"unknown"}]
+
+drop table t_or_def;
+
+-- ===================================
+-- 4. UPDATE OR IGNORE / OR REPLACE — intentionally not supported.
+-- ===================================
+-- Per-statement conflict overrides on UPDATE are SQLite-only syntax; pinned closed.
+-- Schema-level ON CONFLICT on the NOT NULL constraint covers the IGNORE/REPLACE defaults.
+-- See docs/sql.md §11.
+
+-- ===================================
+-- 5. INSERT...SELECT propagates a NOT NULL violation from source
+-- ===================================
+
+create table src (id integer primary key, name text null);
+create table dst (id integer primary key, name text);
+
+insert into src values (1, 'a'), (2, null), (3, 'c');
+
+insert into dst select id, name from src;
+-- error: NOT NULL
+
+-- whole INSERT aborted; nothing committed
+select count(*) as cnt from dst;
+→ [{"cnt":0}]
+
+drop table dst;
+drop table src;

package/test/logic/43.2-deferred-check-new-on-delete.sqllogic

@@ -0,0 +1,95 @@
+-- 43.2-deferred-check-new-on-delete.sqllogic
+-- Regression guard for "No row context found for column <col>" on DELETE.
+--
+-- A deferred CHECK constraint (deferred because it contains a subquery) that
+-- fires `on delete` and references `new.<col>` — typically via
+-- `coalesce(new.<col>, old.<col>)` — used to raise
+--   "No row context found for column <col>"
+-- because the DELETE plan tree ran ConstraintCheckNode against the bare
+-- N-column source row instead of the flat 2N OLD/NEW layout that INSERT/UPDATE
+-- produce. Resolving a NEW attribute (which lives at flat indices n..2n-1) then
+-- indexed past the row. The fix expands the DELETE source row to 2N (OLD section
+-- = values being removed, NEW section = all NULL) BEFORE the constraint check.
+--
+-- This is the quereus-local twin of the sereus CadrePeer `AuthorizedInsert`
+-- check (`coalesce(new, old).PeerId`); see
+-- packages/cadre-core/test/seed-bootstrap.spec.ts on the sereus side.
+
+-- ===================================================================
+-- Setup: a registry lookup + a guarded table whose deferred CHECK fires
+-- on insert AND delete and reads coalesce(new.rkey, old.rkey).
+-- rkey is intentionally a NON-PK column so the NEW reference exercises a
+-- plain flat-row NEW slot rather than any PK-specific path.
+-- ===================================================================
+
+create table registry (rkey text primary key);
+
+create table guarded (
+  id integer primary key,
+  rkey text,
+  constraint key_registered check on insert, delete (
+    exists (select 1 from registry r where r.rkey = coalesce(new.rkey, old.rkey))
+  )
+);
+
+insert into registry values ('alpha');
+insert into guarded values (1, 'alpha');
+commit;
+-- run
+
+select count(*) from guarded;
+→ [{"count(*)":1}]
+
+-- ===================================================================
+-- DELETE: the deferred CHECK references new.rkey, which is NULL in the
+-- all-NULL NEW section on delete; coalesce falls back to old.rkey='alpha',
+-- which IS registered, so the deferred check passes at commit and the row
+-- is removed. Before the fix this raised "No row context found".
+-- ===================================================================
+
+begin;
+delete from guarded where id = 1;
+commit;
+-- run
+
+select count(*) from guarded;
+→ [{"count(*)":0}]
+
+-- ===================================================================
+-- insert→delete→insert cycle: re-insert the same row after the delete and
+-- read it back, exercising the round-trip through the now-coherent flat
+-- OLD/NEW layout (the same cycle the sereus regression test walks).
+-- ===================================================================
+
+begin;
+insert into guarded values (1, 'alpha');
+commit;
+-- run
+
+select id, rkey from guarded;
+→ [{"id":1,"rkey":"alpha"}]
+
+-- ===================================================================
+-- The deferred CHECK genuinely fires on DELETE (not silently skipped):
+-- drop the registry entry first so coalesce(new.rkey, old.rkey)='alpha'
+-- misses, and the deferred check rejects the delete at commit. This proves
+-- NEW/OLD resolve to a real value on the DELETE path rather than the check
+-- being bypassed (which would let scenario 1 pass vacuously).
+-- ===================================================================
+
+begin;
+delete from registry where rkey = 'alpha';
+delete from guarded where id = 1;
+commit;
+-- error: CHECK constraint failed: key_registered
+
+-- Failed commit rolled the whole transaction back: both rows survive.
+select id, rkey from guarded;
+→ [{"id":1,"rkey":"alpha"}]
+
+select rkey from registry;
+→ [{"rkey":"alpha"}]
+
+drop table guarded;
+drop table registry;
+-- run