@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/11.3-mismatched-collation-join.sqllogic

@@ -0,0 +1,74 @@
+-- 11.3-mismatched-collation-join.sqllogic - joins over differently-collated key columns
+--
+-- The planner hash-joins these shapes (ticket join-collation-gate-blocks-hash-join):
+-- a NOCASE-declared column joined to a defaulted-BINARY column resolves to a NOCASE
+-- comparison through the symmetric provenance lattice, so case-variant matches MUST
+-- be returned — identical to what the nested-loop `=` evaluation produced before the
+-- planner change. Merge join is never eligible for these pairs.
+
+-- ===== Collation on the parent (PK) side =====
+
+create table parent (k text collate nocase primary key, v integer);
+create table child (id integer primary key, fk text);
+insert into parent values ('Bob', 1), ('X', 2);
+insert into child values (1, 'bob'), (2, 'BOB'), (3, 'x'), (4, 'zz');
+
+-- INNER: case-variant FK values match the NOCASE parent key
+select c.id as id, p.v as v from child c join parent p on c.fk = p.k order by c.id;
+→ [{"id":1,"v":1},{"id":2,"v":1},{"id":3,"v":2}]
+
+-- INNER with operands flipped in the ON clause (resolution is symmetric)
+select c.id as id, p.v as v from child c join parent p on p.k = c.fk order by c.id;
+→ [{"id":1,"v":1},{"id":2,"v":1},{"id":3,"v":2}]
+
+-- LEFT: the unmatched child row null-pads
+select c.id as id, p.v as v from child c left join parent p on c.fk = p.k order by c.id;
+→ [{"id":1,"v":1},{"id":2,"v":1},{"id":3,"v":2},{"id":4,"v":null}]
+
+-- SEMI via IN: condition contributes nothing (defaulted BINARY), subquery column
+-- contributes declared NOCASE — resolved NOCASE
+select id from child where fk in (select k from parent) order by id;
+→ [{"id":1},{"id":2},{"id":3}]
+
+-- SEMI via correlated EXISTS
+select id from child c where exists (select 1 from parent p where p.k = c.fk) order by id;
+→ [{"id":1},{"id":2},{"id":3}]
+
+-- ANTI via NOT EXISTS
+select id from child c where not exists (select 1 from parent p where p.k = c.fk);
+→ [{"id":4}]
+
+-- ===== Collation on the child (FK) side; fan-out on the BINARY parent column =====
+
+-- A NOCASE probe value matches BOTH binary-distinct parent values 'Bob' and 'bob':
+-- the join must not claim at-most-one match per child row. (`k` is deliberately
+-- NOT the primary key: on the persistent store an undecorated text PK defaults
+-- to the table key collation NOCASE, which would collapse the case-variant rows.)
+create table parent2 (id integer primary key, k text, v integer);
+create table child2 (id integer primary key, fk text collate nocase);
+insert into parent2 values (1, 'Bob', 1), (2, 'bob', 2), (3, 'X', 3), (4, 'zz', 4);
+insert into child2 values (1, 'BOB'), (2, 'x');
+
+select c.id as id, p.v as v from child2 c join parent2 p on c.fk = p.k order by c.id, p.v;
+→ [{"id":1,"v":1},{"id":1,"v":2},{"id":2,"v":3}]
+
+-- DISTINCT over the fanned-out join must not be elided by a false key claim
+select distinct c.id as id from child2 c join parent2 p on c.fk = p.k order by c.id;
+→ [{"id":1},{"id":2}]
+
+-- SEMI: each child row emits once despite the double match
+select id from child2 c where exists (select 1 from parent2 p where p.k = c.fk) order by id;
+→ [{"id":1},{"id":2}]
+
+-- ===== USING over differently-collated columns =====
+
+create table u1 (k text collate nocase, a integer);
+create table u2 (k text, b integer);
+insert into u1 values ('Bob', 1), ('zz', 2);
+insert into u2 values ('bob', 10), ('BOB', 20), ('yy', 30);
+
+select a, b from u1 join u2 using (k) order by a, b;
+→ [{"a":1,"b":10},{"a":1,"b":20}]
+
+select a, b from u1 left join u2 using (k) order by a, b;
+→ [{"a":1,"b":10},{"a":1,"b":20},{"a":2,"b":null}]

package/test/logic/11.4-hash-join-side-swap.sqllogic

@@ -0,0 +1,118 @@
+-- 11.4-hash-join-side-swap.sqllogic
+-- Row-equality coverage for the hash join's build/probe side swap
+-- (rule-join-physical-selection). When the logical LEFT input is the smaller of
+-- the two, an INNER hash join swaps the sides so the smaller one is the hash
+-- build side. The emitted row is then probe-then-build — the reverse of the
+-- logical left-then-right order — and the node's advertised attributes must be
+-- permuted to match. When they were not, any consumer mapping an attribute id
+-- to a column index through the join's attributes and then indexing the row
+-- positionally (the grouped-aggregate emitter is one) read the wrong slot and
+-- silently returned wrong values.
+--
+-- Every assertion here is pure row equality, so it holds whichever physical
+-- join the optimizer picks. The plan-shape assertions (that these shapes DO
+-- swap, and what the swapped node must advertise) live in
+-- test/optimizer/hash-join-side-swap.spec.ts.
+--
+-- NOTE: the 4 x 8 fixture sits near the hash/nested-loop cost crossover
+-- (nl = 7.2 vs hash = 6.4 under today's constants in planner/cost/index.ts).
+-- Because every assertion below is row equality, this file keeps passing if a
+-- cost change stops the swap from firing — it would just stop testing anything.
+-- The spec's "swap fired" assertion is the canary; if it goes red after a cost
+-- change, widen the row counts HERE too rather than only there.
+
+-- 4 x 8 with ANALYZE: hash beats nested loop and the left side is the smaller
+-- one, so the swap fires. Without ANALYZE both sides report the un-analyzed
+-- 100-row sentinel, `leftRows < rightRows` is false, and the swap never happens.
+CREATE TABLE hjs_s (id INTEGER PRIMARY KEY, k INTEGER);
+CREATE TABLE hjs_b (id INTEGER PRIMARY KEY, k INTEGER, v INTEGER);
+INSERT INTO hjs_s VALUES (1,2),(2,1),(3,2),(4,1);
+INSERT INTO hjs_b VALUES (1,2,1),(2,1,2),(3,2,3),(4,1,4),(5,2,5),(6,1,6),(7,2,7),(8,1,8);
+
+-- Each ANALYZE is written as its OWN block with an expected result, not as a
+-- bare setup statement. That expected result is the assertion that the
+-- statistics this whole file depends on actually landed: no row counts, no
+-- side swap, and every case below would pass vacuously.
+ANALYZE hjs_s;
+→ [{"table":"hjs_s","rows":4}]
+
+ANALYZE hjs_b;
+→ [{"table":"hjs_b","rows":8}]
+
+-- ===== The failing shape: a grouped aggregate above the swapped join =====
+-- k=1: s ids {2,4} x b v {2,4,6,8} -> 2 * 20 = 40
+-- k=2: s ids {1,3} x b v {1,3,5,7} -> 2 * 16 = 32
+SELECT s.k AS gk, sum(b.v) AS sv FROM hjs_s s JOIN hjs_b b ON b.k = s.k GROUP BY s.k ORDER BY s.k;
+→ [{"gk":1,"sv":40},{"gk":2,"sv":32}]
+
+-- The aggregate reading the PROBE side's column instead (both sides of the
+-- emitted row must be addressed correctly, not just the build side)
+-- k=1: (2+4) * 4 matching b rows = 24; k=2: (1+3) * 4 = 16
+SELECT s.k AS gk, sum(s.id) AS si FROM hjs_s s JOIN hjs_b b ON b.k = s.k GROUP BY s.k ORDER BY s.k;
+→ [{"gk":1,"si":24},{"gk":2,"si":16}]
+
+-- Grouping on the build-side column, aggregating the probe side
+SELECT b.k AS gk, sum(s.id) AS si FROM hjs_s s JOIN hjs_b b ON b.k = s.k GROUP BY b.k ORDER BY b.k;
+→ [{"gk":1,"si":24},{"gk":2,"si":16}]
+
+-- Both sides aggregated in one grouped query
+SELECT s.k AS gk, sum(b.v) AS sv, sum(s.id) AS si FROM hjs_s s JOIN hjs_b b ON b.k = s.k GROUP BY s.k ORDER BY s.k;
+→ [{"gk":1,"sv":40,"si":24},{"gk":2,"sv":32,"si":16}]
+
+-- ===== Other aggregate kinds over the same swapped join =====
+SELECT s.k AS gk, count(*) AS n, min(b.v) AS mn, max(b.v) AS mx
+FROM hjs_s s JOIN hjs_b b ON b.k = s.k GROUP BY s.k ORDER BY s.k;
+→ [{"gk":1,"n":8,"mn":2,"mx":8},{"gk":2,"n":8,"mn":1,"mx":7}]
+
+-- Ungrouped aggregate over the whole swapped join
+SELECT count(*) AS n, sum(b.v) AS sv, sum(s.id) AS si FROM hjs_s s JOIN hjs_b b ON b.k = s.k;
+→ [{"n":16,"sv":72,"si":40}]
+
+-- ===== The plain projection over the same join =====
+-- Passes even with the bug (column references above the join resolve through
+-- the join emitter's own per-side slots, each built from its own child's
+-- attributes). Kept so a future regression says WHICH consumer style broke.
+SELECT s.id AS sid, b.id AS bid, b.v AS bv FROM hjs_s s JOIN hjs_b b ON b.k = s.k ORDER BY sid, bid;
+→ [{"sid":1,"bid":1,"bv":1},{"sid":1,"bid":3,"bv":3},{"sid":1,"bid":5,"bv":5},{"sid":1,"bid":7,"bv":7},{"sid":2,"bid":2,"bv":2},{"sid":2,"bid":4,"bv":4},{"sid":2,"bid":6,"bv":6},{"sid":2,"bid":8,"bv":8},{"sid":3,"bid":1,"bv":1},{"sid":3,"bid":3,"bv":3},{"sid":3,"bid":5,"bv":5},{"sid":3,"bid":7,"bv":7},{"sid":4,"bid":2,"bv":2},{"sid":4,"bid":4,"bv":4},{"sid":4,"bid":6,"bv":6},{"sid":4,"bid":8,"bv":8}]
+
+-- ===== Sort and DISTINCT key extraction above the swapped join =====
+-- Both resolve attribute ids to column indices through the join's advertised
+-- attributes, so they read the emitted row positionally too.
+SELECT b.v AS bv FROM hjs_s s JOIN hjs_b b ON b.k = s.k ORDER BY bv DESC LIMIT 3;
+→ [{"bv":8},{"bv":8},{"bv":7}]
+
+SELECT DISTINCT s.k AS sk, b.k AS bk FROM hjs_s s JOIN hjs_b b ON b.k = s.k ORDER BY sk;
+→ [{"sk":1,"bk":1},{"sk":2,"bk":2}]
+
+SELECT DISTINCT b.v AS bv FROM hjs_s s JOIN hjs_b b ON b.k = s.k ORDER BY bv;
+→ [{"bv":1},{"bv":2},{"bv":3},{"bv":4},{"bv":5},{"bv":6},{"bv":7},{"bv":8}]
+
+-- ===== Three-table join with the aggregate on top =====
+CREATE TABLE hjs_t (id INTEGER PRIMARY KEY, k INTEGER, w INTEGER);
+INSERT INTO hjs_t VALUES (1,1,100),(2,2,200);
+ANALYZE hjs_t;
+→ [{"table":"hjs_t","rows":2}]
+
+-- Each group is s x b x t = 2 x 4 x 1 = 8 rows.
+-- k=1: sum(b.v) = 2*(2+4+6+8) = 40, sum(t.w) = 8*100 = 800
+-- k=2: sum(b.v) = 2*(1+3+5+7) = 32, sum(t.w) = 8*200 = 1600
+SELECT s.k AS gk, count(*) AS n, sum(b.v) AS sv, sum(t.w) AS tw
+FROM hjs_s s JOIN hjs_b b ON b.k = s.k JOIN hjs_t t ON t.k = s.k
+GROUP BY s.k ORDER BY s.k;
+→ [{"gk":1,"n":8,"sv":40,"tw":800},{"gk":2,"n":8,"sv":32,"tw":1600}]
+
+-- Same spine, plain projection (no aggregate) — one row per (s,b) pair since
+-- each key has exactly one t row
+SELECT s.id AS sid, b.id AS bid, t.w AS tw
+FROM hjs_s s JOIN hjs_b b ON b.k = s.k JOIN hjs_t t ON t.k = s.k
+ORDER BY sid, bid;
+→ [{"sid":1,"bid":1,"tw":200},{"sid":1,"bid":3,"tw":200},{"sid":1,"bid":5,"tw":200},{"sid":1,"bid":7,"tw":200},{"sid":2,"bid":2,"tw":100},{"sid":2,"bid":4,"tw":100},{"sid":2,"bid":6,"tw":100},{"sid":2,"bid":8,"tw":100},{"sid":3,"bid":1,"tw":200},{"sid":3,"bid":3,"tw":200},{"sid":3,"bid":5,"tw":200},{"sid":3,"bid":7,"tw":200},{"sid":4,"bid":2,"tw":100},{"sid":4,"bid":4,"tw":100},{"sid":4,"bid":6,"tw":100},{"sid":4,"bid":8,"tw":100}]
+
+-- ===== HAVING and an aggregate expression above the swapped join =====
+SELECT s.k AS gk, sum(b.v) AS sv FROM hjs_s s JOIN hjs_b b ON b.k = s.k
+GROUP BY s.k HAVING sum(b.v) > 35 ORDER BY s.k;
+→ [{"gk":1,"sv":40}]
+
+SELECT s.k AS gk, sum(b.v) + count(*) AS mixed FROM hjs_s s JOIN hjs_b b ON b.k = s.k
+GROUP BY s.k ORDER BY s.k;
+→ [{"gk":1,"mixed":48},{"gk":2,"mixed":40}]

package/test/logic/110-scan-emitter-mutation-kills.sqllogic

@@ -0,0 +1,121 @@
+-- scan-emitter-mutation-kills.sqllogic — Mutation-killing tests for runtime/emit/scan.ts
+-- Exercises SeqScan and IndexSeek paths through the memory vtab
+-- (the IndexScan paths live in 110.1-scan-emitter-index-scan-kills — they need standalone index DDL)
+
+-- =============================================================================
+-- SeqScan — empty table, single row, multi-row
+-- =============================================================================
+
+create table scan_empty (id integer primary key, val text);
+
+-- Empty table scan returns no rows
+select * from scan_empty;
+→ []
+
+-- Single-row insertion + scan
+insert into scan_empty values (1, 'only');
+select id, val from scan_empty;
+→ [{"id":1,"val":"only"}]
+
+drop table scan_empty;
+
+-- Multi-row sequential scan (verifies iteration loop)
+create table scan_multi (id integer primary key, name text);
+insert into scan_multi values (1, 'alice'), (2, 'bob'), (3, 'charlie');
+
+select id, name from scan_multi order by id;
+→ [{"id":1,"name":"alice"},{"id":2,"name":"bob"},{"id":3,"name":"charlie"}]
+
+-- Larger scan — verify iteration handles multiple rows correctly
+create table scan_many (id integer primary key, v integer);
+insert into scan_many values (1, 10), (2, 20), (3, 30), (4, 40), (5, 50), (6, 60), (7, 70), (8, 80), (9, 90), (10, 100);
+
+-- Verify count
+select count(*) as c from scan_many;
+→ [{"c":10}]
+
+-- Verify sum to catch off-by-one in iteration
+select sum(id) as s from scan_many;
+→ [{"s":55}]
+
+-- Verify first and last
+select id, v from scan_many where id = 1;
+→ [{"id":1,"v":10}]
+
+select id, v from scan_many where id = 10;
+→ [{"id":10,"v":100}]
+
+drop table scan_many;
+
+-- The IndexScan sections (ordered access and range access over a secondary index)
+-- live in 110.1-scan-emitter-index-scan-kills; they need standalone CREATE INDEX.
+
+-- =============================================================================
+-- IndexSeek — point lookup with literal key
+-- =============================================================================
+
+create table seek_pk (id integer primary key, data text);
+insert into seek_pk values (10, 'ten'), (20, 'twenty'), (30, 'thirty');
+
+-- Primary key seek with literal
+select data from seek_pk where id = 20;
+→ [{"data":"twenty"}]
+
+-- Seek miss returns empty
+select data from seek_pk where id = 99;
+→ []
+
+drop table seek_pk;
+
+-- =============================================================================
+-- IndexSeek — composite key
+-- =============================================================================
+
+create table seek_comp (a integer, b integer, val text, primary key (a, b));
+insert into seek_comp values (1, 1, 'one-one'), (1, 2, 'one-two'), (2, 1, 'two-one');
+
+-- Composite key seek
+select val from seek_comp where a = 1 and b = 2;
+→ [{"val":"one-two"}]
+
+-- Partial composite key (range scan on first part)
+select val from seek_comp where a = 1 order by b;
+→ [{"val":"one-one"},{"val":"one-two"}]
+
+drop table seek_comp;
+
+-- =============================================================================
+-- IndexSeek — NULL seek key
+-- =============================================================================
+
+create table seek_null (id integer primary key, val text null);
+insert into seek_null values (1, 'a'), (2, null), (3, 'c');
+
+-- Seek with NULL — should not match anything (NULL ≠ NULL)
+select id from seek_null where val = null;
+→ []
+
+-- IS NULL check
+select id from seek_null where val is null;
+→ [{"id":2}]
+
+drop table seek_null;
+
+-- =============================================================================
+-- SeqScan — verify columns are mapped correctly (row descriptor)
+-- =============================================================================
+
+create table scan_cols (a integer primary key, b text, c real, d integer);
+insert into scan_cols values (1, 'hello', 3.14, 42);
+
+-- Access columns in different orders
+select c, a from scan_cols;
+→ [{"c":3.14,"a":1}]
+
+select d, b, a from scan_cols;
+→ [{"d":42,"b":"hello","a":1}]
+
+drop table scan_cols;
+
+-- Clean up the multi-row table
+drop table scan_multi;

package/test/logic/110.1-scan-emitter-index-scan-kills.sqllogic

@@ -0,0 +1,47 @@
+-- 110.1-scan-emitter-index-scan-kills.sqllogic — Mutation-killing tests for the IndexScan path in runtime/emit/scan.ts
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 110-scan-emitter-mutation-kills: that file's SeqScan and IndexSeek
+-- sections reach their access paths through PRIMARY KEY declarations alone. These
+-- two IndexScan sections use `create index` only to route the plan onto the
+-- secondary-index shape, so they move here and leave the rest of the emitter
+-- coverage runnable on a backend without first-class CREATE INDEX.
+--
+-- Subject: ordered access and range access driven by a secondary index.
+
+-- =============================================================================
+-- IndexScan — ordered access via index
+-- =============================================================================
+
+create table scan_idx (id integer primary key, score integer);
+create index idx_score on scan_idx(score);
+insert into scan_idx values (1, 30), (2, 10), (3, 20);
+
+-- Index scan with ordering by indexed column
+select id, score from scan_idx order by score;
+→ [{"id":2,"score":10},{"id":3,"score":20},{"id":1,"score":30}]
+
+-- Descending index scan
+select id, score from scan_idx order by score desc;
+→ [{"id":1,"score":30},{"id":3,"score":20},{"id":2,"score":10}]
+
+drop table scan_idx;
+
+-- =============================================================================
+-- IndexScan — secondary index with range
+-- =============================================================================
+
+create table scan_range (id integer primary key, v integer);
+create index idx_v on scan_range(v);
+insert into scan_range values (1, 100), (2, 200), (3, 300), (4, 400), (5, 500);
+
+-- Range scan on indexed column
+select id from scan_range where v >= 200 and v <= 400 order by v;
+→ [{"id":2},{"id":3},{"id":4}]
+
+-- Range scan with single bound
+select id from scan_range where v > 300 order by v;
+→ [{"id":4},{"id":5}]
+
+drop table scan_range;

package/test/logic/12-empty-primary-key.sqllogic

@@ -0,0 +1,124 @@
+-- Empty Primary Key Tests (Third Manifesto Feature)
+-- These tests verify support for PRIMARY KEY () which creates singleton tables
+-- that can contain at most 0 or 1 rows
+
+-- Test 1: Create table with empty primary key directly in CREATE TABLE
+CREATE TABLE settings (
+    app_name TEXT NOT NULL,
+    version TEXT,
+    debug_mode INTEGER,
+    PRIMARY KEY ()
+) USING memory;
+
+-- Test 2: Insert first row should succeed
+INSERT INTO settings (app_name, version, debug_mode) VALUES ('MyApp', '1.0.0', 1);
+
+SELECT app_name, version, debug_mode FROM settings;
+→ [{"app_name": "MyApp", "version": "1.0.0", "debug_mode": 1}]
+
+-- Test 3: Second insert should fail (violates singleton constraint)
+INSERT INTO settings (app_name, version, debug_mode) VALUES ('AnotherApp', '2.0.0', 0);
+-- error: UNIQUE constraint failed: settings PK
+
+-- Test 4: Update should work on the single row
+UPDATE settings SET debug_mode = 0 WHERE app_name = 'MyApp';
+
+SELECT app_name, version, debug_mode FROM settings;
+→ [{"app_name": "MyApp", "version": "1.0.0", "debug_mode": 0}]
+
+-- Test 5: Delete should work
+DELETE FROM settings WHERE app_name = 'MyApp';
+
+SELECT app_name, version, debug_mode FROM settings;
+→ []
+
+-- Test 6: After delete, should be able to insert again
+INSERT INTO settings (app_name, version, debug_mode) VALUES ('NewApp', '2.0.0', 1);
+
+SELECT app_name, version, debug_mode FROM settings;
+→ [{"app_name": "NewApp", "version": "2.0.0", "debug_mode": 1}]
+
+-- Test 7: Test with named constraint (using fresh table)
+CREATE TABLE config1 (
+    config_key TEXT,
+    config_value TEXT,
+    CONSTRAINT singleton_config PRIMARY KEY ()
+) USING memory;
+
+-- Test 8: Insert into named constraint table
+INSERT INTO config1 (config_key, config_value) VALUES ('theme', 'dark');
+
+SELECT config_key, config_value FROM config1;
+→ [{"config_key": "theme", "config_value": "dark"}]
+
+-- Test 9: Second insert should fail with named constraint
+INSERT INTO config1 (config_key, config_value) VALUES ('language', 'en');
+-- error: UNIQUE constraint failed: config1 PK
+
+-- Test 10: Test COUNT and aggregation functions on singleton tables
+SELECT COUNT(*) FROM config1;
+→ [{"count(*)": 1}]
+
+SELECT COUNT(*) FROM settings;
+→ [{"count(*)": 1}]
+
+-- Test 11: Test with transactions using fresh table
+CREATE TABLE config2 (
+    config_key TEXT,
+    config_value TEXT,
+    PRIMARY KEY ()
+) USING memory;
+
+INSERT INTO config2 (config_key, config_value) VALUES ('app_theme', 'light');
+
+BEGIN;
+DELETE FROM config2;
+INSERT INTO config2 (config_key, config_value) VALUES ('temp_config', 'temp_value');
+
+SELECT config_key, config_value FROM config2;
+→ [{"config_key": "temp_config", "config_value": "temp_value"}]
+
+ROLLBACK;
+
+-- Should be back to previous state
+SELECT config_key, config_value FROM config2;
+→ [{"config_key": "app_theme", "config_value": "light"}]
+
+-- Test 12: Test with savepoints
+SAVEPOINT sp1;
+UPDATE config2 SET config_value = 'very_dark';
+
+SELECT config_key, config_value FROM config2;
+→ [{"config_key": "app_theme", "config_value": "very_dark"}]
+
+ROLLBACK TO sp1;
+
+SELECT config_key, config_value FROM config2;
+→ [{"config_key": "app_theme", "config_value": "light"}]
+
+RELEASE sp1;
+
+-- Test 13: Test JOIN with singleton tables
+CREATE TABLE users (
+    id INTEGER PRIMARY KEY,
+    name TEXT
+) USING memory;
+
+INSERT INTO users (id, name) VALUES (1, 'Alice'), (2, 'Bob');
+
+-- Cross join with singleton should produce one row per regular table row
+SELECT u.id, u.name, c.config_value 
+FROM users u 
+CROSS JOIN config2 c
+ORDER BY u.id;
+→ [{"id": 1, "name": "Alice", "config_value": "light"}, {"id": 2, "name": "Bob", "config_value": "light"}]
+
+-- Test 14: Test singleton tables work with ORDER BY and LIMIT
+SELECT config_key, config_value FROM config2 ORDER BY config_key LIMIT 5;
+→ [{"config_key": "app_theme", "config_value": "light"}]
+
+-- Test 15: Cleanup
+DROP TABLE IF EXISTS settings;
+DROP TABLE IF EXISTS config1;
+DROP TABLE IF EXISTS config2;
+DROP TABLE IF EXISTS users;

package/test/logic/12-join_padding_order.sqllogic

@@ -0,0 +1,58 @@
+-- Test suite for LEFT JOIN NULL padding and ORDER BY consumption
+
+-- Setup Tables
+CREATE TABLE t1 (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO t1 VALUES (1, 'A'), (2, 'B'), (3, 'C');
+
+CREATE TABLE t2 (id INTEGER PRIMARY KEY, t1_id INTEGER, info TEXT);
+INSERT INTO t2 VALUES (101, 1, 'InfoA1'), (102, 1, 'InfoA2'), (103, 2, 'InfoB');
+-- Note: t1.id = 3 has no match in t2
+
+-- ==================================
+-- LEFT JOIN Padding Tests
+-- ==================================
+
+-- Test: Direct Output Padding
+-- Expect t2 columns to be NULL for t1.id = 3
+SELECT t1.id, t1.val, t2.id, t2.info FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id ORDER BY t1.id, t2.id;
+→ [{"id":1,"val":"A","id:1":101,"info":"InfoA1"},{"id":1,"val":"A","id:1":102,"info":"InfoA2"},{"id":2,"val":"B","id:1":103,"info":"InfoB"},{"id":3,"val":"C","id:1":null,"info":null}]
+
+-- Test: Aggregate COUNT Padding
+-- COUNT(t2.id) should be 0 for the group corresponding to t1.id = 3
+SELECT t1.id, COUNT(t2.id) as count_t2, COUNT(*) as count_all FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id GROUP BY t1.id ORDER BY t1.id;
+→ [{"id":1,"count_t2":2,"count_all":2},{"id":2,"count_t2":1,"count_all":1},{"id":3,"count_t2":0,"count_all":1}]
+
+-- Test: Aggregate SUM Padding
+-- SUM(t2.id) should be NULL (ignored NULLs) for the group corresponding to t1.id = 3
+SELECT t1.id, SUM(t2.id) as sum_t2 FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id GROUP BY t1.id ORDER BY t1.id;
+→ [{"id":1,"sum_t2":203},{"id":2,"sum_t2":103},{"id":3,"sum_t2":null}]
+
+-- Test: Window Function ROW_NUMBER Padding
+-- Partitioning by t1.id should work correctly, rows with NULL t2.id get numbered
+SELECT t1.id, t2.id as t2_id, ROW_NUMBER() OVER (PARTITION BY t1.id ORDER BY t2.id) as rn
+FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id
+ORDER BY t1.id, t2.id;
+→ [{"id":1,"t2_id":101,"rn":1},{"id":1,"t2_id":102,"rn":2},{"id":2,"t2_id":103,"rn":1},{"id":3,"t2_id":null,"rn":1}]
+
+-- Test: Window Function SUM Padding
+-- SUM(t2.id) OVER (...) should treat NULL t2.id correctly based on frame
+SELECT t1.id, t2.id as t2_id,
+       SUM(t2.id) OVER (PARTITION BY t1.id ORDER BY t2.id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as running_sum
+FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id
+ORDER BY t1.id, t2.id;
+→ [{"id":1,"t2_id":101,"running_sum":101},{"id":1,"t2_id":102,"running_sum":203},{"id":2,"t2_id":103,"running_sum":103},{"id":3,"t2_id":null,"running_sum":null}]
+
+-- ==================================
+-- ORDER BY Consumption Tests
+-- ==================================
+-- The secondary-index variants (ORDER BY consumed / not consumed on an indexed
+-- column) live in 12.1-orderby-index-consumption; they need standalone CREATE INDEX.
+
+-- Test: ORDER BY on JOIN result (Likely Not Consumed)
+-- Order by t1.val, join order might not preserve this. Expect Sort.
+SELECT t1.val, t2.info FROM t1 JOIN t2 ON t1.id = t2.t1_id ORDER BY t1.val DESC, t2.id ASC;
+→ [{"val":"B","info":"InfoB"},{"val":"A","info":"InfoA1"},{"val":"A","info":"InfoA2"}]
+
+DROP TABLE t1;
+DROP TABLE t2;
+

package/test/logic/12.1-orderby-index-consumption.sqllogic

@@ -0,0 +1,40 @@
+-- 12.1-orderby-index-consumption.sqllogic — ORDER BY consumed (or not) by a secondary index.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 12-join_padding_order: that file's subject is LEFT JOIN NULL
+-- padding through direct output, aggregates and window functions, none of which
+-- needs an index. This section builds an indexed table only so the planner can
+-- elide the Sort node, so it moves here rather than costing a backend without
+-- first-class CREATE INDEX the whole padding suite.
+--
+-- Subject: ORDER BY on the indexed column (ASC and DESC) is satisfied by the index
+-- ordering; ORDER BY on another column or on an expression is not, and must still
+-- return correctly sorted rows through a Sort.
+
+-- Setup Indexed Table for ORDER BY consumption test
+CREATE TABLE t_idx (id INTEGER PRIMARY KEY, name TEXT);
+CREATE INDEX t_idx_name ON t_idx (name);
+INSERT INTO t_idx VALUES (1, 'Xavier'), (2, 'Alice'), (3, 'Bob');
+
+-- Test: ORDER BY Consumed by Index (ASC)
+-- Expect query plan to use index on t_idx.name, no Sort operation needed
+SELECT name FROM t_idx ORDER BY name ASC;
+→ [{"name":"Alice"},{"name":"Bob"},{"name":"Xavier"}]
+
+-- Test: ORDER BY Consumed by Index (DESC)
+-- Expect query plan to use index on t_idx.name (backwards), no Sort operation needed
+SELECT name FROM t_idx ORDER BY name DESC;
+→ [{"name":"Xavier"},{"name":"Bob"},{"name":"Alice"}]
+
+-- Test: ORDER BY Not Consumed (Different Column)
+-- Expect query plan to use PK for scan, requires Sort operation
+SELECT name FROM t_idx ORDER BY id DESC;
+→ [{"name":"Bob"},{"name":"Alice"},{"name":"Xavier"}]
+
+-- Test: ORDER BY Not Consumed (Expression)
+-- Expect query plan to use PK for scan, requires Sort operation
+SELECT name FROM t_idx ORDER BY lower(name);
+→ [{"name":"Alice"},{"name":"Bob"},{"name":"Xavier"}]
+
+DROP TABLE t_idx;