@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/03.6.1-numeric-text-comparison-coercion.sqllogic

@@ -0,0 +1,244 @@
+-- 03.6.1-numeric-text-comparison-coercion.sqllogic
+-- Regression coverage for bug-numeric-text-coercion-skips-in-and-case:
+-- `insertCrossTypeCoercion` (planner/building/coercion.ts) casts the textual side
+-- of a numeric-vs-textual comparison so `int_col = '1'` reads as `int_col = 1`.
+-- That rule used to apply only at the `=`/BETWEEN build sites; `IN` value lists,
+-- simple CASE, nullif/greatest/least, the IN-subquery runtime path
+-- (`inMembershipKeys`, runtime/emit/subquery.ts) and both IN decorrelation
+-- rewrites (rule-subquery-decorrelation.ts) skipped it, so the SAME comparison
+-- answered differently depending on how it was spelled. This file pins every
+-- form agreeing with each other over an INTEGER column, a REAL column and a
+-- TEXT column.
+--
+-- Section 6 pins the follow-on rule from
+-- bug-comparison-coercion-corrupts-returned-value: the three builtins that RETURN
+-- one of their arguments convert only a copy for the comparison, so the value
+-- handed back is the argument as written.
+
+create table nn (id integer primary key, i integer, r real);
+insert into nn values (1, 1, 2.5);
+-- run
+
+create table tt (id integer primary key, t text);
+insert into tt values (1, '1');
+-- run
+
+-- ===================================
+-- 1. INTEGER column `i` (value 1) against textual operands — every form agrees
+-- ===================================
+select (i = '1') as v from nn;
+→ [{"v":true}]
+
+select (i between '0' and '2') as v from nn;
+→ [{"v":true}]
+
+select i in ('1') as v from nn;
+→ [{"v":true}]
+
+select i in (select t from tt) as v from nn;
+→ [{"v":true}]
+
+select case i when '1' then 'hit' else 'miss' end as v from nn;
+→ [{"v":"hit"}]
+
+select nullif(i, '1') as v from nn;
+→ [{"v":null}]
+
+-- `greatest`/`least`/`nullif` compare CONVERTED copies but return the ORIGINAL
+-- argument, so the winner here is the text '2' the user wrote, not the INTEGER 2
+-- the conversion produced. Section 6 pins that rule on its own; here the point is
+-- that the comparison still ranks '2' above the integer 1.
+select greatest(i, '2') as v from nn;
+→ [{"v":"2"}]
+
+-- `least` is unaffected here (1 is already the smaller value either way) — kept
+-- as a control that the coercion did not change an already-correct answer.
+select least(i, '2') as v from nn;
+→ [{"v":1}]
+
+-- An INTEGER column against fractional text: the text side converts to NUMERIC
+-- (its full numeric value, 1.9), NOT to INTEGER — the prefix parse (`cast('1.9'
+-- as integer)` is 1) used to decide these comparisons and made `i = '1.9'` true
+-- for i = 1. Every form agrees on the numeric reading.
+select (i = '1.9') as v from nn;
+→ [{"v":false}]
+
+select i in ('1.9') as v from nn;
+→ [{"v":false}]
+
+select case i when '1.9' then 'hit' else 'miss' end as v from nn;
+→ [{"v":"miss"}]
+
+-- ===================================
+-- 2. REAL column `r` (value 2.5) against textual operands
+-- ===================================
+select (r = '2.5') as v from nn;
+→ [{"v":true}]
+
+select (r between '2' and '3') as v from nn;
+→ [{"v":true}]
+
+select r in ('2.5') as v from nn;
+→ [{"v":true}]
+
+select case r when '2.5' then 'hit' else 'miss' end as v from nn;
+→ [{"v":"hit"}]
+
+-- ===================================
+-- 3. TEXT column `t` (value '1') against numeric operands — the reverse pairing
+-- ===================================
+select (t = 1) as v from tt;
+→ [{"v":true}]
+
+select (t between 0 and 2) as v from tt;
+→ [{"v":true}]
+
+select t in (1) as v from tt;
+→ [{"v":true}]
+
+select t in (select i from nn) as v from tt;
+→ [{"v":true}]
+
+select case t when 1 then 'hit' else 'miss' end as v from tt;
+→ [{"v":"hit"}]
+
+-- A NULL member does not defeat the hoisted probe cast (it is filtered out of the
+-- all-numeric test), and the three-valued result still holds: a hit is true, a
+-- miss over a list containing NULL is NULL rather than false.
+select t in (1, null) as v from tt;
+→ [{"v":true}]
+
+select t in (9, null) as v from tt;
+→ [{"v":null}]
+
+select t not in (0, 2) as v from tt;
+→ [{"v":true}]
+
+select t not in (1, 2) as v from tt;
+→ [{"v":false}]
+
+-- Mixed INTEGER/REAL member list widens the hoisted probe cast to NUMERIC rather
+-- than picking a lossy winner, so a textual '1' still matches the integer member.
+select t in (1, 2.5) as v from tt;
+→ [{"v":true}]
+
+-- ===================================
+-- 4. Negative controls — must NOT change, and are the things a future
+--    "simplification" of the coercion would most likely break
+-- ===================================
+
+-- A non-numeric textual value never matches, in any form.
+select i in ('abc') as v from nn;
+→ [{"v":false}]
+
+-- IN with a NULL member stays three-valued: NULL, not false.
+select i in (null) as v from nn;
+→ [{"v":null}]
+
+-- NOT IN is the plain complement over a NULL-free list.
+select i not in ('2') as v from nn;
+→ [{"v":true}]
+
+-- Mixed-WHEN simple CASE: `i` is numeric, so each WHEN casts independently —
+-- this is the per-value path, not the hoisted-probe one, and is not the gap
+-- below. (The parser requires a THEN per WHEN, so `when '1' when 2` is a
+-- syntax error, not a shape to test.)
+select case i when 'abc' then 'a' when '1' then 'b' else 'c' end as v from nn;
+→ [{"v":"b"}]
+
+-- ===================================
+-- 5. The one remaining known gap: a TEXTUAL probe against a value list mixing
+--    numeric and textual values. `coerceComparisonSet` deliberately declines to
+--    hoist a probe cast over a MIXED list — `cast('abc' as real)` is 0, so
+--    hoisting would make `s in (1, 'abc')` true for a stored '0'. The trade is a
+--    visible disagreement with the `=` disjunction on the numeric member; see
+--    the NOTE on `coerceComparisonSet` (planner/building/coercion.ts) and
+--    docs/types.md "Type Coercion in Comparisons" for why closing it needs a
+--    per-value probe that IN cannot express.
+-- ===================================
+create table nc_mix (id integer primary key, s text);
+insert into nc_mix values (1, '0'), (2, '1');
+-- run
+
+-- Stored '0': IN and the `=` disjunction agree (both false) — this one is fine.
+select s in (1, 'abc') as v from nc_mix where id = 1;
+→ [{"v":false}]
+
+select (s = 1 or s = 'abc') as v from nc_mix where id = 1;
+→ [{"v":false}]
+
+-- Stored '1': THIS is where the gap is visible. `s in (1, 'abc')` stays
+-- uncoerced (false), but `s = 1 or s = 'abc'` reconciles the pairwise `=` and
+-- matches (true). Pinned deliberately as a known, documented divergence —
+-- not a typo.
+select s in (1, 'abc') as v from nc_mix where id = 2;
+→ [{"v":false}]
+
+select (s = 1 or s = 'abc') as v from nc_mix where id = 2;
+→ [{"v":true}]
+
+-- ===================================
+-- 6. Comparison answers unchanged, RETURNED values original
+--    (bug-comparison-coercion-corrupts-returned-value)
+--
+--    `nullif`, `greatest` and `least` each return one of their arguments. The
+--    coercion above used to REPLACE that argument with its cast, so the cast's
+--    output was what came back: `greatest(t, 1)` handed back the integer 3 for the
+--    stored text '3', and `least('abc', 1)` handed back 0 — a value that was never
+--    an argument at all (`cast('abc' as integer)` is 0). Those three now coerce
+--    comparison KEYS at emit time (`makeComparisonGroup`,
+--    runtime/emit/operand-comparator.ts) and return the raw argument.
+-- ===================================
+
+create table t3 (id integer primary key, s text);
+insert into t3 values (1, '3');
+-- run
+
+-- The returned value is the argument as written, storage class included.
+select nullif('3', 1) as v, typeof(nullif('3', 1)) as t;
+→ [{"v":"3","t":"text"}]
+
+select nullif(s, 1) as v, typeof(nullif(s, 1)) as ty from t3;
+→ [{"v":"3","ty":"text"}]
+
+-- A non-numeric text argument: the comparison converts it to 0 and so does not
+-- match 1, but 0 must never be the RESULT.
+select nullif('abc', 1) as v;
+→ [{"v":"abc"}]
+
+-- Regression guard against over-correcting: the comparison itself must still
+-- coerce, so a matching numeric text still nulls out — and '1.9' reads as the
+-- NUMERIC 1.9 (no INTEGER truncation), so it does NOT match i = 1, exactly as
+-- `i = '1.9'` answers false in section 1.
+select nullif(i, '1') as a, nullif(i, '1.9') as b from nn;
+→ [{"a":null,"b":1}]
+
+-- Both orientations of the mixed pair. Argument order decides which side carries
+-- the conversion (probe cast vs value cast), so both must be covered; either way
+-- the result is one of the arguments, never 0.
+select least('abc', 1) as v, typeof(least('abc', 1)) as t;
+→ [{"v":"abc","t":"text"}]
+
+select least(1, 'abc') as v, typeof(least(1, 'abc')) as t;
+→ [{"v":"abc","t":"text"}]
+
+-- The comparison still picks the numerically larger/smaller argument across the
+-- category boundary — it is only the returned spelling that changed.
+select greatest(1, '2') as g, typeof(greatest(1, '2')) as gt;
+→ [{"g":"2","gt":"text"}]
+
+select least(1, '2') as l, typeof(least(1, '2')) as lt;
+→ [{"l":1,"lt":"integer"}]
+
+-- A TEXT column on the probe side, the shape from the bug report.
+select greatest(s, 1) as g, typeof(greatest(s, 1)) as gt from t3;
+→ [{"g":"3","gt":"text"}]
+
+-- Control: `coalesce` picks by nullness, not by comparison, so it declares no
+-- comparison group and was never affected — it already returned its argument.
+select coalesce(s, 1) as v, typeof(coalesce(s, 1)) as ty from t3;
+→ [{"v":"3","ty":"text"}]
+
+-- Control: a same-category group still returns the plain winner.
+select greatest(1, 2) as g, least(1, 2) as l;
+→ [{"g":2,"l":1}]

package/test/logic/03.6.2-value-to-text.sqllogic

@@ -0,0 +1,224 @@
+-- 03.6.2-value-to-text.sqllogic
+-- ONE value-to-text conversion (src/util/value-text.ts) behind every site that has
+-- to render a value as text: CAST / text() / TEXT-column writes, `||`, LIKE operand
+-- coercion, and group_concat. The real invariant is AGREEMENT — the same value must
+-- spell the same way whichever construct produced it. Per-type unit coverage lives in
+-- test/util/value-text.spec.ts; this file pins the SQL-visible behaviour.
+
+-- === Per-source-type table ===
+
+select cast('hello' as text) as r;
+→ [{"r":"hello"}]
+
+select cast(123 as text) as r;
+→ [{"r":"123"}]
+
+select cast(3.14 as text) as r;
+→ [{"r":"3.14"}]
+
+select cast(true as text) as r;
+→ [{"r":"true"}]
+
+select cast(false as text) as r;
+→ [{"r":"false"}]
+
+select cast(null as text) as r;
+→ [{"r":null}]
+
+-- Bigint: exact decimal digits, no Number() round-trip.
+select cast(cast('9007199254740993' as integer) as text) as r;
+→ [{"r":"9007199254740993"}]
+
+-- Blob: UTF-8 decode. Was hex ('6162') through CAST and decimal bytes ('97,98')
+-- through `||`; both now read the bytes as text, the way SQLite does.
+select cast(x'6162' as text) as r;
+→ [{"r":"ab"}]
+
+-- The conversion function shares the rule (it is TEXT_TYPE.parse).
+select text(x'6162') as r;
+→ [{"r":"ab"}]
+
+-- JSON object: the document's own text, not the placeholder '[object Object]'.
+select cast(json('{"a":1}') as text) as r;
+→ [{"r":"{\"a\":1}"}]
+
+-- JSON array: real JSON, not the JS Array.toString() spelling '1,2,3'.
+select cast(json('[1,2,3]') as text) as r;
+→ [{"r":"[1,2,3]"}]
+
+-- Nested document survives whole.
+select cast(json('{"a":{"x":1},"b":[1,null]}') as text) as r;
+→ [{"r":"{\"a\":{\"x\":1},\"b\":[1,null]}"}]
+
+-- Key order is the DOCUMENT's, deliberately not canonical (sorted) order:
+-- canonical form is for grouping keys and fingerprints, not for display.
+select cast(json('{"b":2,"a":1}') as text) as r;
+→ [{"r":"{\"b\":2,\"a\":1}"}]
+
+-- === Edge cases ===
+
+-- Empty blob renders as the empty string, not NULL.
+select cast(x'' as text) as r;
+→ [{"r":""}]
+
+-- BOM: the decoder is built with ignoreBOM, so EF BB BF stays ONE U+FEFF
+-- character instead of being silently stripped to ''.
+select length(cast(x'efbbbf' as text)) as r;
+→ [{"r":1}]
+
+-- Invalid UTF-8 becomes U+FFFD. This is LOSSY on purpose — the conversion has to
+-- be total (castCanYieldNull declares TEXT total over non-null operands), so it
+-- replaces rather than throws.
+select cast(x'ff' as text) as r;
+→ [{"r":"�"}]
+
+-- ...and the loss is real: distinct invalid blobs collide onto the same text.
+-- Pinned so nobody "fixes" the replacement behaviour by accident.
+select cast(x'ff' as text) = cast(x'fe' as text) as r;
+→ [{"r":true}]
+
+-- Multi-byte sequences decode properly.
+select cast(x'e4b8ad' as text) as r;
+→ [{"r":"中"}]
+
+-- A JSON column holding a string scalar is physically a JS string, so it renders
+-- bare — the conversion dispatches on the runtime value and cannot see that the
+-- declared type is JSON.
+select cast(json('"hello"') as text) as r;
+→ [{"r":"hello"}]
+
+-- JSON null parses to SQL NULL, so the cast is NULL — not the text 'null'.
+select cast(json('null') as text) as r;
+→ [{"r":null}]
+
+-- cast(<json> as blob) is the UTF-8 of the document's text ('{"a":1}'),
+-- not of '[object Object]'.
+select cast(json('{"a":1}') as blob) = x'7b2261223a317d' as r;
+→ [{"r":true}]
+
+-- === NULL propagation is unchanged ===
+
+select null || 'x' as r;
+→ [{"r":null}]
+
+select 'x' || null as r;
+→ [{"r":null}]
+
+select cast(null as text) is null as r;
+→ [{"r":true}]
+
+-- === Concatenation, LIKE and group_concat use the same rule ===
+
+create table vt_b (id integer primary key, b blob);
+insert into vt_b values (1, x'6162'), (2, x'6163');
+-- run
+
+select b || '' as r from vt_b order by id;
+→ [{"r":"ab"},{"r":"ac"}]
+
+select id from vt_b where b like 'ab' order by id;
+→ [{"id":1}]
+
+-- Same LIKE through a non-constant pattern, so the dynamic per-row path is
+-- exercised too: constLikePattern and emitLikeOp must derive the same string.
+select id from vt_b where b like (select b from vt_b where id = 1) order by id;
+→ [{"id":1}]
+
+select group_concat(b) as r from vt_b;
+→ [{"r":"ab,ac"}]
+
+select group_concat(b, '-') as r from vt_b;
+→ [{"r":"ab-ac"}]
+
+-- === The agreement invariants ===
+
+-- CAST and `||` derive the same text for every row.
+select cast(b as text) = (b || '') as r from vt_b order by id;
+→ [{"r":true},{"r":true}]
+
+-- group_concat over the raw values agrees with group_concat over the cast values.
+select group_concat(b) = group_concat(cast(b as text)) as r from vt_b;
+→ [{"r":true}]
+
+-- LIKE's operand coercion agrees with CAST.
+select b like cast(b as text) as r from vt_b order by id;
+→ [{"r":true},{"r":true}]
+
+-- The `like` FUNCTION is the same operation as the LIKE operator, so it must derive
+-- the same text. (It used to use JS stringification and answer false here.)
+select like(cast(b as text), b) = (b like cast(b as text)) as r from vt_b order by id;
+→ [{"r":true},{"r":true}]
+
+select like('ab', x'6162') as r;
+→ [{"r":true}]
+
+-- glob() shares the coercion with like().
+select glob('ab', x'6162') as r;
+→ [{"r":true}]
+
+-- Same for a JSON document rendered as its own text.
+select like('%"a"%', json('{"a":1}')) as r;
+→ [{"r":true}]
+
+-- Same three-way agreement over a JSON value.
+create table vt_j (id integer primary key, j json);
+insert into vt_j values (1, '{"a":1}'), (2, '[1,2,3]');
+-- run
+
+select cast(j as text) = (j || '') as r from vt_j order by id;
+→ [{"r":true},{"r":true}]
+
+select group_concat(j) as r from vt_j;
+→ [{"r":"{\"a\":1},[1,2,3]"}]
+
+-- group_concat still skips NULLs.
+create table vt_n (id integer primary key, v text null);
+insert into vt_n values (1, 'a'), (2, null), (3, 'b');
+-- run
+
+select group_concat(v) as r from vt_n;
+→ [{"r":"a,b"}]
+
+-- === The write path stores the conversion, not just the display ===
+
+-- Inserting a blob into a TEXT column now STORES the UTF-8 decode (was the hex
+-- spelling). This changes stored values, and it is lossy for non-UTF-8 bytes.
+create table vt_w (id integer primary key, t text);
+insert into vt_w values (1, x'6162'), (2, x'e4b8ad');
+-- run
+
+select t from vt_w order by id;
+→ [{"t":"ab"},{"t":"中"}]
+
+select typeof(t) as ty from vt_w order by id;
+→ [{"ty":"text"},{"ty":"text"}]
+
+-- An ALTER that retypes a BLOB column to TEXT backfills through the same rule.
+create table vt_r (id integer primary key, b blob);
+insert into vt_r values (1, x'6162');
+alter table vt_r alter column b set data type text;
+-- run
+
+select b from vt_r order by id;
+→ [{"b":"ab"}]
+
+-- A TEXT column DEFAULT written as a blob literal folds through the same rule.
+create table vt_d (id integer primary key, t text default x'6162');
+insert into vt_d (id) values (1);
+-- run
+
+select t from vt_d;
+→ [{"t":"ab"}]
+
+-- === `->>` comes along for free ===
+-- The parser desugars `a ->> b` to cast(json_extract(a, b) as text), so fixing
+-- CAST fixes the operator.
+
+select '{"a":{"x":1}}' ->> 'a' as r;
+→ [{"r":"{\"x\":1}"}]
+
+select '{"a":[1,2]}' ->> 'a' as r;
+→ [{"r":"[1,2]"}]
+
+select '{"a":"s"}' ->> 'a' as r;
+→ [{"r":"s"}]

package/test/logic/03.7-bigint-mixed-arithmetic.sqllogic

@@ -0,0 +1,65 @@
+-- bigint-mixed-arithmetic.sqllogic - Test mixed bigint/number arithmetic
+-- Regression: mixed bigint + number silently returns null instead of numeric result
+
+-- 9007199254740993 exceeds Number.MAX_SAFE_INTEGER, so it's stored as bigint
+-- Adding a float (1.5) to it should produce float arithmetic, not null
+-- Note: converting bigint to Number loses precision (expected for float ops)
+
+SELECT 9007199254740993 + 1.5;
+→ [{"9007199254740993 + 1.5":9007199254740994}]
+
+-- bigint + integer (number): number promotes to bigint, stays in bigint domain
+SELECT 9007199254740993 + 1;
+→ [{"9007199254740993 + 1":9007199254740994}]
+
+-- bigint - number (float) — test harness returns bare value for subtraction expressions
+SELECT 9007199254740993 - 0.5;
+→ [9007199254740992]
+
+-- bigint * number (integer 2.0 promotes to BigInt)
+SELECT 9007199254740993 * 2.0;
+→ [{"9007199254740993 * 2.0":18014398509481986}]
+
+-- number + bigint (reversed operand order)
+SELECT 1.5 + 9007199254740993;
+→ [{"1.5 + 9007199254740993":9007199254740994}]
+
+-- bigint / number
+SELECT 9007199254740993 / 2.0;
+→ [{"9007199254740993 / 2.0":4503599627370496}]
+
+-- bigint % number (integer 2.0 promotes to BigInt, gives exact result)
+SELECT 9007199254740993 % 2.0;
+→ [{"9007199254740993 % 2.0":1}]
+
+-- Verify pure bigint + bigint still works
+SELECT 9007199254740993 + 9007199254740993;
+→ [{"9007199254740993 + 9007199254740993":18014398509481986}]
+
+-- Verify typeof results
+-- Float result is 9007199254740994 which is integer-valued (IEEE 754 rounding)
+SELECT typeof(9007199254740993 + 1.5);
+→ [{"typeof(9007199254740993 + 1.5)":"integer"}]
+
+SELECT typeof(9007199254740993 + 1);
+→ [{"typeof(9007199254740993 + 1)":"integer"}]
+
+-- bigint + numeric string: text coerced through arithmetic affinity, then BigInt-promoted
+SELECT 9007199254740993 + '3';
+→ [{"9007199254740993 + '3'":9007199254740996}]
+
+-- numeric string + bigint (reversed order)
+SELECT '3' + 9007199254740993;
+→ [{"'3' + 9007199254740993":9007199254740996}]
+
+-- bigint + non-numeric string: string coerces to 0, stays in BigInt domain
+SELECT 9007199254740993 + 'abc';
+→ [{"9007199254740993 + 'abc'":9007199254740993}]
+
+-- bigint + boolean: boolean coerces to 0/1, BigInt-promoted
+SELECT 9007199254740993 + true;
+→ [{"9007199254740993 + true":9007199254740994}]
+
+-- bigint + fractional numeric string: float path
+SELECT 9007199254740993 + '0.5';
+→ [{"9007199254740993 + '0.5'":9007199254740992}]