@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/09.1-set-op-cross-collation.sqllogic

@@ -0,0 +1,230 @@
+-- Set-operation cross-input collation merge. Ticket
+-- set-operation-cross-input-collation-merge. Each set-op output column resolves
+-- its dedup/compare collation across BOTH inputs through the same provenance-
+-- ranked comparison lattice (explicit > declared > default > BINARY, symmetric,
+-- plan-time error on same-rank explicit/declared conflicts) used by ordinary
+-- comparisons and join keys. The resolved collation is written into the node's
+-- output column/attribute types, so the dedup/membership comparator AND an
+-- enclosing ORDER BY both read it from there — lockstep is structural.
+--
+-- DISTINCT operators (UNION/INTERSECT/EXCEPT/DIFF) dedup, so a same-rank
+-- explicit/declared conflict is a prepare-time error; UNION ALL does no dedup,
+-- so it never errors (it propagates no collation, like `||` / CASE).
+-- See docs/types.md § Comparison collation resolution (set operations).
+
+create table cl (id integer primary key, n text collate nocase, p text, r text collate rtrim);
+create table cr (id integer primary key, n text collate nocase, p text, r text collate rtrim);
+insert into cl values (1, 'Apple', 'Apple', 'Apple'), (2, 'Banana', 'Banana', 'Banana');
+insert into cr values (1, 'apple', 'apple', 'apple'), (2, 'cherry', 'cherry', 'cherry');
+
+-- =============================================================================
+-- 1. Branch-order symmetry (the headline fix). A declared-NOCASE column on one
+--    side and a plain (defaulted-BINARY) column on the other resolves NOCASE
+--    from EITHER branch order, so the union dedups case-insensitively both ways
+--    ('Apple'/'apple' fold → 3 distinct, not 4). Previously the LEFT input's
+--    collation alone drove dedup, so swapping branches flipped NOCASE↔BINARY.
+-- =============================================================================
+
+select count(*) as c from (select n from cl union select p from cr);
+→ [{"c":3}]
+
+-- reversed: declared NOCASE now on the right; identical dedup (was BINARY → 4).
+select count(*) as c from (select p from cr union select n from cl);
+→ [{"c":3}]
+
+-- =============================================================================
+-- 2. Explicit COLLATE both sides. Same name resolves and dedups under it;
+--    different names are a rank-3 prepare-time conflict (both orders).
+-- =============================================================================
+
+select count(*) as c from (select n collate nocase from cl union select p collate nocase from cr);
+→ [{"c":3}]
+
+select n collate nocase from cl union select p collate rtrim from cr;
+-- error: conflicting COLLATE clauses
+
+select p collate rtrim from cr union select n collate nocase from cl;
+-- error: conflicting COLLATE clauses
+
+-- =============================================================================
+-- 3. Declared both sides. Same declared collation resolves; different declared
+--    collations are a rank-2 ambiguous-collation error (both orders). An
+--    explicit COLLATE on one side disambiguates.
+-- =============================================================================
+
+select count(*) as c from (select n from cl union select n from cr);
+→ [{"c":3}]
+
+select n from cl union select r from cr;
+-- error: ambiguous collation
+
+select r from cr union select n from cl;
+-- error: ambiguous collation
+
+-- explicit COLLATE outranks the conflicted declared pair (rank 3 > rank 2).
+select count(*) as c from (select n from cl union select r collate nocase from cr);
+→ [{"c":3}]
+
+-- =============================================================================
+-- 4. Default-vs-default conflict resolves to BINARY SILENTLY (no error) —
+--    defaults are preferences, not declarations. Tables created under different
+--    session default_collations. 'Bob'/'bob' fold only under NOCASE, 'bob '/'bob'
+--    only under RTRIM; under BINARY all three are distinct, so 3 proves BINARY.
+-- =============================================================================
+
+pragma default_collation='nocase';
+create table dn (id integer primary key, v text);
+pragma default_collation='rtrim';
+create table dr (id integer primary key, w text);
+pragma default_collation='binary';
+
+insert into dn values (1, 'Bob'), (2, 'bob ');
+insert into dr values (1, 'bob');
+
+select count(*) as c from (select v from dn union select w from dr);
+→ [{"c":3}]
+select count(*) as c from (select w from dr union select v from dn);
+→ [{"c":3}]
+
+drop table dn;
+drop table dr;
+
+-- =============================================================================
+-- 5. UNION ALL never errors. Two divergent EXPLICIT collations would be a hard
+--    conflict for any DISTINCT operator, but UNION ALL does no dedup, so the
+--    output column carries no collation and every input row passes through
+--    unchanged (bag: 2 + 2 = 4). This is the easiest place to wrongly throw.
+-- =============================================================================
+
+select count(*) as c from (select n collate nocase from cl union all select p collate rtrim from cr);
+→ [{"c":4}]
+
+-- divergent DECLARED collations under UNION ALL: also no error.
+select count(*) as c from (select n from cl union all select r from cr);
+→ [{"c":4}]
+
+-- =============================================================================
+-- 6. INTERSECT / EXCEPT membership follows the SAME resolved collation as UNION
+--    over the same inputs. Under NOCASE: 'Apple' ∩ {'apple','cherry'} matches
+--    (1 row); {'Apple','Banana'} − {'apple','cherry'} keeps only 'Banana' (1
+--    row). Under BINARY these would be 0 and 2.
+-- =============================================================================
+
+select count(*) as c from (select n from cl intersect select p from cr);
+→ [{"c":1}]
+select count(*) as c from (select n from cl except select p from cr);
+→ [{"c":1}]
+
+-- INTERSECT yields the LEFT row; it still reports the resolved collation.
+select n from cl intersect select p from cr;
+→ [{"n":"Apple"}]
+select n from cl except select p from cr;
+→ [{"n":"Banana"}]
+
+-- =============================================================================
+-- 7. Nested set operations / forward propagation. The inner union resolves to
+--    NOCASE at rank 2 (declared wins over the plain side), and that rank rides
+--    into the inner node's OUTPUT column collation. The outer union then sees
+--    NOCASE(2) vs declared RTRIM(2) → conflict. Were the inner rank demoted to
+--    1, RTRIM would silently win — so the error firing pins rank propagation.
+-- =============================================================================
+
+(select n from cl union select p from cr) union select r from cr;
+-- error: ambiguous collation
+
+-- inner resolves NOCASE, outer NOCASE vs declared NOCASE → resolves (no error).
+-- Deterministic union order (left-first, input order): Apple, Banana, cherry.
+(select n from cl union select p from cr) union select n from cr;
+→ [{"n":"Apple"},{"n":"Banana"},{"n":"cherry"}]
+
+-- =============================================================================
+-- 8. Multi-column alignment. Each column resolves independently; a conflict in
+--    ANY column errors the whole statement even when the others resolve. Here
+--    column 1 resolves (NOCASE both) but column 2 conflicts (NOCASE vs RTRIM).
+-- =============================================================================
+
+create table m1 (id integer primary key, a text collate nocase, b text collate nocase);
+create table m2 (id integer primary key, a text collate nocase, b text collate rtrim);
+insert into m1 values (1, 'x', 'y');
+insert into m2 values (1, 'x', 'y');
+
+select a, b from m1 union select a, b from m2;
+-- error: ambiguous collation
+
+drop table m1;
+drop table m2;
+
+-- =============================================================================
+-- 9. ORDER BY lockstep (end-to-end). The outer ORDER BY keys off the union's
+--    RESOLVED output-column collation (NOCASE), not the left input's raw type.
+--    'apple' < 'banana' < 'Cherry' under NOCASE; under BINARY 'Cherry' (C=67)
+--    would sort before the lowercase letters, so the order proves NOCASE.
+-- =============================================================================
+
+create table o1 (id integer primary key, n text collate nocase);
+create table o2 (id integer primary key, p text);
+insert into o1 values (1, 'banana');
+insert into o2 values (1, 'Cherry'), (2, 'apple');
+
+select n from o1 union select p from o2 order by n;
+→ [{"n":"apple"},{"n":"banana"},{"n":"Cherry"}]
+
+-- Ordinal form keys off the SAME resolved NOCASE output column (ticket
+-- compound-order-by-ordinal-reference): `order by 1` resolves to output column 1
+-- and inherits its resolved collation, so it sorts identically to the name form.
+select n from o1 union select p from o2 order by 1;
+→ [{"n":"apple"},{"n":"banana"},{"n":"Cherry"}]
+
+drop table o1;
+drop table o2;
+
+-- =============================================================================
+-- 10. Membership-flag set operations. Data columns resolve cross-input; the
+--     appended `exists … as` flag columns are never touched. The data column
+--     still dedups under the resolved NOCASE (3 distinct), and a divergent
+--     declared data-column collation still errors on the DATA column only.
+-- =============================================================================
+
+select count(*) as c from (select n from cl union exists left as inL select p from cr);
+→ [{"c":3}]
+
+select n from cl union exists left as inL select r from cr;
+-- error: ambiguous collation
+
+-- =============================================================================
+-- 11. DIFF (symmetric difference) expands to (A except B) union (B except A);
+--     each nested except is a DISTINCT operator, so divergent declared
+--     collations surface the conflict. A resolving DIFF folds under NOCASE:
+--     {'Banana'} ∪ {'cherry'} = 2 (BINARY would give 4).
+-- =============================================================================
+
+select n from cl diff select r from cr;
+-- error: ambiguous collation
+
+select count(*) as c from (select n from cl diff select p from cr);
+→ [{"c":2}]
+
+-- =============================================================================
+-- 12. Materialized view over a cross-collation UNION. The union's resolved
+--     output-column collation flows through `deriveBackingShape` into the
+--     backing column (its provenance — declared here — publishes an explicit
+--     backing collation), so the materialized result dedups under the SAME
+--     resolved NOCASE the plain view would (3, not 4), in BOTH branch orders.
+--     Locks in the implement handoff's highest-value gap (gap #3): an MV body's
+--     union persists the symmetric resolved collation, not the left input's.
+-- =============================================================================
+
+create materialized view mv_xc as select n from cl union select p from cr;
+select count(*) as c from mv_xc;
+→ [{"c":3}]
+
+-- reversed branch order persists the same NOCASE backing (was BINARY → 4).
+create materialized view mv_xc2 as select p from cr union select n from cl;
+select count(*) as c from mv_xc2;
+→ [{"c":3}]
+
+drop materialized view mv_xc;
+drop materialized view mv_xc2;
+
+drop table cl;
+drop table cr;

package/test/logic/10-distinct_datatypes.sqllogic

@@ -0,0 +1,127 @@
+-- distinct_datatypes.sqllogic - Testing DISTINCT operations and data type behavior
+
+-- Test DISTINCT operations
+CREATE TABLE distinct_test (id INTEGER PRIMARY KEY, category TEXT, value INTEGER);
+INSERT INTO distinct_test VALUES
+    (1, 'A', 100),
+    (2, 'B', 200),
+    (3, 'A', 100),
+    (4, 'B', 300),
+    (5, 'A', 200);
+
+-- Basic DISTINCT
+SELECT DISTINCT category FROM distinct_test ORDER BY category;
+→ [{"category":"A"},{"category":"B"}]
+
+-- DISTINCT with multiple columns
+SELECT DISTINCT category, value FROM distinct_test ORDER BY category, value;
+→ [{"category":"A","value":100},{"category":"A","value":200},{"category":"B","value":200},{"category":"B","value":300}]
+
+-- DISTINCT with expressions
+SELECT DISTINCT category, value * 2 as doubled FROM distinct_test ORDER BY category, doubled;
+→ [{"category":"A","doubled":200},{"category":"A","doubled":400},{"category":"B","doubled":400},{"category":"B","doubled":600}]
+
+-- DISTINCT in subqueries
+SELECT category, (SELECT COUNT(DISTINCT value) FROM distinct_test d2 WHERE d2.category = d1.category) as unique_values
+FROM distinct_test d1
+GROUP BY category
+ORDER BY category;
+→ [{"category":"A","unique_values":2},{"category":"B","unique_values":2}]
+
+DROP TABLE distinct_test;
+
+-- Data type behavior tests
+CREATE TABLE types_test (
+    id INTEGER PRIMARY KEY,
+    int_val INTEGER,
+    real_val REAL,
+    text_val TEXT,
+    blob_val BLOB,
+    null_val NULL
+);
+
+INSERT INTO types_test VALUES
+    (1, 42, 3.14, 'hello', x'deadbeef', NULL),
+    (2, -10, 0.0, '', x'', NULL),
+    (3, 0, -1.5, 'world', x'ff', NULL);
+
+-- Test type coercion and comparison
+SELECT int_val = '42' FROM types_test WHERE id = 1;
+→ [{"int_val = '42'":true}]
+
+-- Test NULL handling
+SELECT null_val IS NULL, null_val = NULL FROM types_test WHERE id = 1;
+→ [{"null_val is null":true,"null_val = null":null}]
+
+-- Test type functions
+SELECT typeof(int_val), typeof(real_val), typeof(text_val), typeof(blob_val), typeof(null_val)
+FROM types_test WHERE id = 1;
+→ [{"typeof(int_val)":"integer","typeof(real_val)":"real","typeof(text_val)":"text","typeof(blob_val)":"blob","typeof(null_val)":"null"}]
+
+-- Test comparison across types
+SELECT int_val < real_val FROM types_test WHERE id = 1;
+→ [{"int_val < real_val":false}]
+
+-- Test text/numeric conversion
+SELECT '123' + 0, 'abc' + 0, '' + 0;
+→ [{"'123' + 0":123,"'abc' + 0":0,"'' + 0":0}]
+
+-- Test type affinity in tables
+CREATE TABLE affinity_test (
+    int_col INTEGER,
+    real_col REAL,
+    text_col TEXT,
+    blob_col BLOB,
+    numeric_col NUMERIC
+);
+
+INSERT INTO affinity_test VALUES ('123', '45.6', 789, 'text_as_blob', '999.99');
+SELECT typeof(int_col), typeof(real_col), typeof(text_col), typeof(blob_col), typeof(numeric_col)
+FROM affinity_test;
+→ [{"typeof(int_col)":"integer","typeof(real_col)":"real","typeof(text_col)":"text","typeof(blob_col)":"blob","typeof(numeric_col)":"real"}]
+
+DROP TABLE affinity_test;
+DROP TABLE types_test;
+
+-- Type coercion consistency tests
+CREATE TABLE coerce_test (id INTEGER PRIMARY KEY, a ANY, b ANY);
+
+-- Test numeric coercion consistency
+INSERT INTO coerce_test VALUES (1, 5, '3'), (2, '2.5', 4), (3, true, false);
+
+-- Expression should work consistently in different contexts
+SELECT (a + b) FROM coerce_test WHERE id = 1;
+→ [{"a + b":8}]
+
+SELECT id FROM coerce_test WHERE (a + b) = 8;
+→ [{"id":1}]
+
+SELECT (a + b) FROM coerce_test WHERE id = 2;
+→ [{"a + b":6.5}]
+
+SELECT id FROM coerce_test WHERE (a + b) = 6.5;
+→ [{"id":2}]
+
+-- Boolean arithmetic
+SELECT (a + b) FROM coerce_test WHERE id = 3;
+→ [{"a + b":1}]
+
+SELECT id FROM coerce_test WHERE (a + b) = 1;
+→ [{"id":3}]
+
+-- Test string/numeric boundary cases
+DELETE FROM coerce_test;
+INSERT INTO coerce_test VALUES (1, '10', '20'), (2, 'abc', 'def');
+
+-- Numeric strings should work
+SELECT (a + b) FROM coerce_test WHERE id = 1;
+→ [{"a + b":30}]
+
+-- Non-numeric strings should fail gracefully - test that it errors consistently
+-- error: Invalid operation
+-- SELECT (a + b) FROM coerce_test WHERE id = 2;
+
+-- error: Invalid operation
+-- SELECT id FROM coerce_test WHERE (a + b) = 'should_fail';
+
+DROP TABLE coerce_test;

package/test/logic/10.1-ddl-lifecycle.sqllogic

@@ -0,0 +1,203 @@
+-- DDL lifecycle: CREATE, INSERT, ALTER, DROP, and schema+transaction interaction
+
+-- ===================================
+-- 1. Basic DDL Lifecycle
+-- ===================================
+-- CREATE TABLE → INSERT data → verify → DROP TABLE → verify table gone
+
+create table lifecycle (id integer primary key, name text);
+
+insert into lifecycle values (1, 'Alice'), (2, 'Bob');
+
+select * from lifecycle order by id;
+→ [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]
+
+-- Verify count
+select count(*) as cnt from lifecycle;
+→ [{"cnt": 2}]
+
+-- Update a row
+update lifecycle set name = 'Alicia' where id = 1;
+
+select name from lifecycle where id = 1;
+→ [{"name": "Alicia"}]
+
+-- Delete a row
+delete from lifecycle where id = 2;
+
+select count(*) as cnt from lifecycle;
+→ [{"cnt": 1}]
+
+-- Drop the table
+drop table lifecycle;
+
+-- Verify table is gone
+select * from lifecycle;
+-- error: not found in schema path
+
+-- ===================================
+-- 2. IF NOT EXISTS / IF EXISTS
+-- ===================================
+
+create table safe_create (id integer primary key, val text);
+insert into safe_create values (1, 'original');
+
+-- CREATE TABLE IF NOT EXISTS on existing table is a no-op
+create table if not exists safe_create (id integer primary key, val text);
+
+-- Data should be intact (not reset)
+select val from safe_create where id = 1;
+→ [{"val": "original"}]
+
+-- Insert still works
+insert into safe_create values (2, 'added');
+
+select count(*) as cnt from safe_create;
+→ [{"cnt": 2}]
+
+-- DROP TABLE IF EXISTS on existing table removes it
+drop table if exists safe_create;
+
+-- DROP TABLE IF EXISTS on missing table is a no-op
+drop table if exists safe_create;
+
+-- Verify table is gone
+select * from safe_create;
+-- error: not found in schema path
+
+-- ===================================
+-- 3. CREATE INDEX Lifecycle
+-- ===================================
+-- Lives in 10.1.5-create-index-lifecycle (it needs standalone index DDL).
+
+-- ===================================
+-- 4. Schema + Transaction Interaction
+-- ===================================
+-- Note: Schema (DDL) changes take effect immediately and are NOT
+-- rolled back by transaction rollback. Only data changes are rolled back.
+
+-- 4a. INSERT data, BEGIN, INSERT more, ROLLBACK — new inserts gone, old data intact
+create table tx_schema (id integer primary key, val text);
+insert into tx_schema values (1, 'committed');
+
+begin;
+insert into tx_schema values (2, 'will-rollback');
+
+select count(*) as cnt from tx_schema;
+→ [{"cnt": 2}]
+
+rollback;
+
+-- Row 2 should be rolled back, row 1 intact
+select count(*) as cnt from tx_schema;
+→ [{"cnt": 1}]
+
+select val from tx_schema where id = 1;
+→ [{"val": "committed"}]
+
+-- 4b. Data committed inside explicit transaction persists
+begin;
+insert into tx_schema values (3, 'will-commit');
+commit;
+
+select val from tx_schema where id = 3;
+→ [{"val": "will-commit"}]
+
+-- 4c. Rollback undoes deletes too
+begin;
+delete from tx_schema where id = 1;
+
+select count(*) as cnt from tx_schema;
+→ [{"cnt": 1}]
+
+rollback;
+
+-- Row 1 should be restored
+select count(*) as cnt from tx_schema;
+→ [{"cnt": 2}]
+
+-- 4d. Rollback undoes updates
+begin;
+update tx_schema set val = 'changed' where id = 1;
+
+select val from tx_schema where id = 1;
+→ [{"val": "changed"}]
+
+rollback;
+
+select val from tx_schema where id = 1;
+→ [{"val": "committed"}]
+
+drop table tx_schema;
+
+-- ===================================
+-- 5. Error Cases
+-- ===================================
+
+-- 5a. CREATE TABLE with duplicate name
+create table dup_table (x integer);
+
+create table dup_table (y integer);
+-- error: already exists
+
+drop table dup_table;
+
+-- 5b. DROP TABLE on non-existent table
+drop table no_such_table;
+-- error: not found
+
+-- 5c. CREATE TABLE with duplicate column names
+create table dup_cols (a integer, a text);
+-- error: Duplicate column name
+
+-- 5d-5f. The CREATE INDEX rejections (unknown table, unknown column, duplicate index
+-- name) live in 10.1.5-create-index-lifecycle § 2.
+
+-- ===================================
+-- 6. Multi-table DDL Sequence
+-- ===================================
+-- Verify creating, using, and dropping multiple tables in sequence
+
+create table t_first (id integer primary key, label text);
+create table t_second (id integer primary key, ref_id integer, data text);
+
+insert into t_first values (10, 'ten'), (20, 'twenty');
+insert into t_second values (1, 10, 'alpha'), (2, 20, 'beta');
+
+select f.label, s.data
+from t_first f join t_second s on f.id = s.ref_id
+order by f.id;
+→ [{"label": "ten", "data": "alpha"}, {"label": "twenty", "data": "beta"}]
+
+-- Drop in reverse dependency order
+drop table t_second;
+drop table t_first;
+
+-- Both tables should be gone
+select * from t_first;
+-- error: not found in schema path
+
+select * from t_second;
+-- error: not found in schema path
+
+-- ===================================
+-- 7. Re-create Table After Drop
+-- ===================================
+-- Verify a table can be re-created with a different schema after drop
+
+create table reuse (x integer primary key);
+insert into reuse values (1), (2);
+
+select count(*) as cnt from reuse;
+→ [{"cnt": 2}]
+
+drop table reuse;
+
+-- Re-create with different columns
+create table reuse (a text, b real);
+insert into reuse values ('hello', 3.14);
+
+select a, b from reuse;
+→ [{"a": "hello", "b": 3.14}]
+
+drop table reuse;

package/test/logic/10.1.1-create-table-syntax-edges.sqllogic

@@ -0,0 +1,47 @@
+-- adapted from SQLite test/createtab.test
+-- CREATE TABLE syntax edge cases not covered by 10.1-ddl-lifecycle / 10.2-column-features.
+
+-- ===================================
+-- 1. Untyped columns: SQLite-specific dynamic typing.
+-- Deleted: Quereus has strict typed columns; untyped declarations don't apply.
+-- ===================================
+
+-- ===================================
+-- 2. CREATE TABLE while iterating an existing table
+-- ===================================
+-- Cursor-stability across DDL: a new table must be createable while a cursor
+-- on a different table is open / a prior CTE-like read pipeline is in flight.
+
+create table cs1 (id integer primary key, v text);
+insert into cs1 values (1, 'aaa'), (2, 'bbb'), (3, 'ccc'), (4, 'ddd');
+
+-- Iterate via CTE, then create another table; both should work
+with iter as (select id from cs1)
+select count(*) as cnt from iter;
+→ [{"cnt":4}]
+
+create table cs2 (id integer primary key, v text);
+insert into cs2 values (1, 'one'), (2, 'two');
+
+select count(*) as cnt from cs1;
+→ [{"cnt":4}]
+
+select count(*) as cnt from cs2;
+→ [{"cnt":2}]
+
+-- Several CREATE TABLE in sequence
+create table cs3 (id integer primary key);
+create table cs4 (id integer primary key);
+
+select name from schema() where type = 'table' and name like 'cs_' order by name;
+→ [{"name":"cs1"},{"name":"cs2"},{"name":"cs3"},{"name":"cs4"}]
+
+drop table cs1;
+drop table cs2;
+drop table cs3;
+drop table cs4;
+
+-- ===================================
+-- 3. Duplicate column in UNIQUE: SQLite-specific rejection.
+-- Deleted: Quereus does not specifically reject duplicate columns in UNIQUE.
+-- ===================================