@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/15.1.1-json-check-coercion.sqllogic

@@ -0,0 +1,178 @@
+-- 15.1.1-json-check-coercion.sqllogic
+-- A CHECK constraint must compare JSON values exactly the way a later `select`
+-- compares the stored row.
+--
+-- The DML emitters convert the NEW row to declared column types at the top of
+-- the pipeline (driven by static types — docs/types.md § Where coercion
+-- happens), so ConstraintCheckNode reads parsed JSON values, never the raw text
+-- the statement supplied. Before that held, an immediate CHECK compared two raw
+-- JSON texts letter-by-letter, so '{"a":10}' sorted before '{"a":2}' and a
+-- perfectly valid row was rejected.
+-- Regression for bug-json-compare-string-ambiguity; the structural order itself
+-- is covered by 15.1-semantic-ordering.sqllogic.
+
+-- === Immediate CHECK over two JSON columns: structural, not textual ===
+
+create table jcc (id integer primary key, a json, b json, check (a < b));
+
+-- Text order would place '{"a":10}' before '{"a":2}' and reject this row;
+-- structural order is 2 < 10, so it is accepted.
+insert into jcc values (1, '{"a":2}', '{"a":10}');
+
+select count(*) as c from jcc;
+→ [{"c":1}]
+
+-- The read path agrees with the CHECK that admitted the row.
+select (a < b) as r from jcc;
+→ [{"r":true}]
+
+-- The check is not vacuous: the reversed pair is genuinely rejected.
+insert into jcc values (2, '{"a":10}', '{"a":2}');
+-- error: CHECK
+
+-- Equal values are not less-than either.
+insert into jcc values (3, '{"a":2}', '{"a":2}');
+-- error: CHECK
+
+-- JSON type rank (number < string) is enforced at insert time too. As raw text
+-- '"a"' sorts BEFORE '5' (the quote character precedes the digit), so a
+-- text-order check would reject this row and accept the reversed one.
+insert into jcc values (4, '5', '"a"');
+
+select count(*) as c from jcc;
+→ [{"c":2}]
+
+insert into jcc values (5, '"a"', '5');
+-- error: CHECK
+
+drop table jcc;
+
+-- === The deferred path reaches the same verdict as the immediate one ===
+
+-- A subquery-bearing CHECK auto-defers to the DeferredConstraintQueue, which is
+-- handed the same coerced row. Same comparison, same accept/reject decisions.
+create table jcc_def (id integer primary key, a json, b json, check ((select a < b)));
+
+insert into jcc_def values (1, '{"a":2}', '{"a":10}');
+
+select count(*) as c from jcc_def;
+→ [{"c":1}]
+
+insert into jcc_def values (2, '{"a":10}', '{"a":2}');
+-- error: CHECK
+
+insert into jcc_def values (3, '5', '"a"');
+
+select count(*) as c from jcc_def;
+→ [{"c":2}]
+
+insert into jcc_def values (4, '"a"', '5');
+-- error: CHECK
+
+drop table jcc_def;
+
+-- === UPDATE goes through the same coerced NEW section ===
+
+create table jcc_upd (id integer primary key, a json, b json, check (a < b));
+
+insert into jcc_upd values (1, '{"a":2}', '{"a":10}');
+
+update jcc_upd set b = '{"a":30}' where id = 1;
+
+select b from jcc_upd;
+→ [{"b":{"a":30}}]
+
+update jcc_upd set a = '{"a":90}' where id = 1;
+-- error: CHECK
+
+select a from jcc_upd;
+→ [{"a":{"a":2}}]
+
+drop table jcc_upd;
+
+-- === JSON string scalars in a CHECK honour the declared collation ===
+
+-- A JSON column can hold a string scalar: '"Bob"' coerces to the bare string
+-- Bob, so the CHECK compares two strings and a supplied collation applies. JSON
+-- declares no supported collations, so the collation can only arrive as an
+-- explicit COLLATE wrapper (`create table ... j json collate nocase` is rejected
+-- at DDL) — which is exactly how the read path spells it too.
+
+create table jcc_coll (id integer primary key, a json, b json, check (a = b collate nocase));
+
+insert into jcc_coll values (1, '"Bob"', '"bob"');
+
+select count(*) as c from jcc_coll;
+→ [{"c":1}]
+
+-- A JSON string scalar round-trips as the bare string, not as quoted JSON text.
+select a, b from jcc_coll;
+→ [{"a":"Bob","b":"bob"}]
+
+-- Read path agrees with the CHECK that admitted the row.
+select count(*) as c from jcc_coll where a = b collate nocase;
+→ [{"c":1}]
+
+-- Genuinely different strings are still rejected under NOCASE.
+insert into jcc_coll values (2, '"Bob"', '"bib"');
+-- error: CHECK
+
+drop table jcc_coll;
+
+-- Control: with no declared collation the comparison is BINARY, so the same
+-- case-variant pair is rejected.
+create table jcc_bin (id integer primary key, a json, b json, check (a = b));
+
+insert into jcc_bin values (1, '"Bob"', '"bob"');
+-- error: CHECK
+
+insert into jcc_bin values (2, '"Bob"', '"Bob"');
+
+select a from jcc_bin;
+→ [{"a":"Bob"}]
+
+drop table jcc_bin;
+
+-- === A substituted NOT NULL DEFAULT converts its own cell exactly once ===
+
+-- A NOT NULL DEFAULT substituted under OR REPLACE is injected AFTER the emitters'
+-- conversion pass, so it does two separable things.
+--
+-- What it READS is the ordinary declared form every write-path expression sees
+-- (docs/invariants.md RT-001, pinned across all four write sites by
+-- 15.1.3-declared-form-write-contract.sqllogic): `new.j` below is the parsed
+-- document `Bob`, not the raw text '"Bob"' the statement spelled.
+--
+-- What it WRITES is its own injected cell, which still needs converting — and
+-- that conversion must not re-apply `parse`, because `JSON_TYPE.parse` is not
+-- idempotent for a string scalar (`'"Bob"'` → `Bob`, and re-parsing `Bob`
+-- throws). The identity-plus-conformance guard in `buildCellCoercion` is what
+-- makes it a no-op here: `new.j` announces JSON and the value in hand inhabits
+-- JSON, so the cell is left alone.
+
+create table jcc_def_raw (id integer primary key, j json, k json not null default (new.j), check (id > 0));
+
+insert or replace into jcc_def_raw values (1, '"Bob"', null);
+
+select id, j, k from jcc_def_raw;
+→ [{"id":1,"j":"Bob","k":"Bob"}]
+
+-- An object value round-trips the same way (parse IS idempotent for these, so
+-- this case passed even while the string-scalar one threw).
+insert or replace into jcc_def_raw values (2, '{"a":2}', null);
+
+select k from jcc_def_raw where id = 2;
+→ [{"k":{"a":2}}]
+
+drop table jcc_def_raw;
+
+-- Control: the same shape on a table with NO check expressions at all, which
+-- takes the skip-the-copy path in ConstraintCheckNode.
+create table jcc_def_nochk (id integer primary key, j json, k json not null default (new.j));
+
+insert or replace into jcc_def_nochk values (1, '"Bob"', null);
+
+select id, j, k from jcc_def_nochk;
+→ [{"id":1,"j":"Bob","k":"Bob"}]
+
+drop table jcc_def_nochk;

package/test/logic/15.1.2-semantic-ordering-index.sqllogic

@@ -0,0 +1,41 @@
+-- 15.1.2-semantic-ordering-index.sqllogic — semantic ordering through standalone index DDL.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 15.1-semantic-ordering: that file proves the semantic-ordering rule
+-- (docs/types.md "Semantic ordering") across ORDER BY, comparisons, BETWEEN, PK
+-- order and range scans, DISTINCT/GROUP BY/set-operation identity, windows and
+-- joins — none of which needs index DDL. Two scenarios reached the same rule via a
+-- standalone index (one a secondary-index access path, one a `create unique index`
+-- restatement of a UNIQUE identity check the file already makes via a table-level
+-- constraint), so they move here.
+--
+-- Subject: the typed compare governs a secondary index's seek/range/ordering, and
+-- an index-derived UNIQUE enforces the same identity at write time.
+
+-- Secondary index: seek, range and ordering all run under the tree's typed order.
+create table si (id integer primary key, d timespan);
+create index si_d on si(d);
+insert into si values (1, 'PT2H'), (2, 'PT90M'), (3, 'PT30M');
+
+select id from si order by d;
+→ [{"id":3},{"id":2},{"id":1}]
+
+select id from si where d > 'PT90M';
+→ [{"id":1}]
+
+select id from si where d = 'PT120M';
+→ [{"id":1}]
+
+drop table si;
+
+-- `create unique index` enforces the same identity at WRITE time (the build-time
+-- dedup over pre-existing rows already did).
+create table ui (id integer primary key, d timespan);
+create unique index ui_d on ui (d);
+insert into ui values (1, 'PT1H');
+
+insert into ui values (2, 'PT60M');
+-- error: UNIQUE constraint failed
+
+drop table ui;