@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/10.5.2-expression-indexes.sqllogic

@@ -0,0 +1,34 @@
+-- adapted from SQLite test/index.test, test/index1.test, test/expridx.test ideas
+-- expression indexes: CREATE INDEX ... ON tab(<expr>)
+-- Quereus's parser accepts expressions in indexed-column lists, but the schema
+-- manager rejects them at index-build time. This fixture pins the rejection so
+-- that future support can flip the assertions in one place.
+--
+-- requires-capability: standalone-index-ddl
+
+-- =====================================================
+-- 1. Function-call expression in CREATE INDEX is rejected
+-- =====================================================
+create table e_upper (id integer primary key, name text);
+create index ix_e_upper_name on e_upper(upper(name));
+-- error: not supported
+
+drop table e_upper;
+
+-- =====================================================
+-- 2. Arithmetic expression in CREATE INDEX is rejected
+-- =====================================================
+create table e_arith (id integer primary key, a integer, b integer);
+create index ix_e_arith_sum on e_arith(a + b);
+-- error: not supported
+
+drop table e_arith;
+
+-- =====================================================
+-- 3. UNIQUE expression index is rejected at the same point
+-- =====================================================
+create table e_uniq (id integer primary key, name text);
+create unique index ix_e_uniq_lower on e_uniq(lower(name));
+-- error: not supported
+
+drop table e_uniq;

package/test/logic/10.5.3-desc-index-ordering.sqllogic

@@ -0,0 +1,130 @@
+-- adapted from SQLite test/descidx1.test, descidx2.test, descidx3.test
+-- DESC indexes for output ordering. Companion to 40.1-pk-desc-direction (PK DESC)
+-- and 10.5-indexes (single-column DESC creation). Pins composite mixed-direction
+-- indexes, NULL ordering through DESC indexes, and range queries on DESC indexes.
+--
+-- requires-capability: standalone-index-ddl
+
+-- =====================================================
+-- 1. Single-column DESC index — descending traversal
+-- =====================================================
+create table d_one (id integer primary key, score integer);
+insert into d_one values (1, 30);
+insert into d_one values (2, 10);
+insert into d_one values (3, 50);
+insert into d_one values (4, 20);
+insert into d_one values (5, 40);
+
+create index ix_d_one_score on d_one(score desc);
+
+-- ORDER BY DESC matches the index direction
+select id, score from d_one order by score desc;
+→ [{"id":3,"score":50},{"id":5,"score":40},{"id":1,"score":30},{"id":4,"score":20},{"id":2,"score":10}]
+
+-- ORDER BY ASC also correct (engine may reverse-scan or sort, either way result is right)
+select id, score from d_one order by score;
+→ [{"id":2,"score":10},{"id":4,"score":20},{"id":1,"score":30},{"id":5,"score":40},{"id":3,"score":50}]
+
+drop table d_one;
+
+-- =====================================================
+-- 2. Composite mixed-direction index (ASC, DESC)
+-- =====================================================
+create table d_mix (id integer primary key, category text, score integer);
+insert into d_mix values (1, 'a', 10);
+insert into d_mix values (2, 'a', 30);
+insert into d_mix values (3, 'a', 20);
+insert into d_mix values (4, 'b', 5);
+insert into d_mix values (5, 'b', 25);
+
+create index ix_d_mix on d_mix(category asc, score desc);
+
+-- ORDER BY matching the index direction exactly
+select id, category, score from d_mix order by category asc, score desc;
+→ [{"id":2,"category":"a","score":30},{"id":3,"category":"a","score":20},{"id":1,"category":"a","score":10},{"id":5,"category":"b","score":25},{"id":4,"category":"b","score":5}]
+
+-- Equality on the leading key followed by DESC scan of the trailing key
+select id, score from d_mix where category = 'a' order by score desc;
+→ [{"id":2,"score":30},{"id":3,"score":20},{"id":1,"score":10}]
+
+drop table d_mix;
+
+-- =====================================================
+-- 3. DESC index with NULLs
+-- =====================================================
+create table d_null (id integer primary key, val text null);
+insert into d_null values (1, 'z');
+insert into d_null values (2, null);
+insert into d_null values (3, 'a');
+insert into d_null values (4, null);
+insert into d_null values (5, 'm');
+
+create index ix_d_null on d_null(val desc);
+
+-- Bare DESC sort. The engine places NULLs FIRST for BOTH directions -- placement is
+-- absolute, never conditioned on ASC/DESC. A DESC index walk emits them LAST, so the
+-- index must decline the ordering claim here and leave the Sort in place; the answer is
+-- the same with or without ix_d_null.
+select val from d_null order by val desc;
+→ [{"val":null},{"val":null},{"val":"z"},{"val":"m"},{"val":"a"}]
+
+-- A NULL-excluding filter evicts every NULL, so the DESC index may claim the ordering
+-- again -- the exception that keeps `where val is not null order by val desc` fast.
+select val from d_null where val is not null order by val desc;
+→ [{"val":"z"},{"val":"m"},{"val":"a"}]
+
+-- Explicit NULLs FIRST under DESC
+select val from d_null order by val desc nulls first;
+→ [{"val":null},{"val":null},{"val":"z"},{"val":"m"},{"val":"a"}]
+
+-- Explicit NULLs LAST under DESC
+select val from d_null order by val desc nulls last;
+→ [{"val":"z"},{"val":"m"},{"val":"a"},{"val":null},{"val":null}]
+
+drop table d_null;
+
+-- =====================================================
+-- 4. Range scan on DESC index
+-- =====================================================
+create table d_range (id integer primary key, n integer);
+insert into d_range values (1, 100);
+insert into d_range values (2, 50);
+insert into d_range values (3, 75);
+insert into d_range values (4, 25);
+insert into d_range values (5, 90);
+
+create index ix_d_range on d_range(n desc);
+
+-- Half-bounded range, DESC ordering
+select n from d_range where n >= 60 order by n desc;
+→ [{"n":100},{"n":90},{"n":75}]
+
+-- Bounded range, DESC ordering
+select n from d_range where n between 30 and 80 order by n desc;
+→ [{"n":75},{"n":50}]
+
+-- Same bounded range, ASC ordering still correct
+select n from d_range where n between 30 and 80 order by n;
+→ [{"n":50},{"n":75}]
+
+drop table d_range;
+
+-- =====================================================
+-- 5. DESC index on TEXT — lexicographic descending
+-- =====================================================
+create table d_text (id integer primary key, name text);
+insert into d_text values (1, 'banana');
+insert into d_text values (2, 'apple');
+insert into d_text values (3, 'cherry');
+insert into d_text values (4, 'date');
+
+create index ix_d_text on d_text(name desc);
+
+select name from d_text order by name desc;
+→ [{"name":"date"},{"name":"cherry"},{"name":"banana"},{"name":"apple"}]
+
+-- Range on TEXT DESC index
+select name from d_text where name >= 'b' order by name desc;
+→ [{"name":"date"},{"name":"cherry"},{"name":"banana"}]
+
+drop table d_text;

package/test/logic/10.5.4-composite-pk-index-update-phantom.sqllogic

@@ -0,0 +1,55 @@
+-- 10.5.4-composite-pk-index-update-phantom.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Regression: a composite-PK table with a secondary index on a non-PK column.
+-- Updating (or deleting) the indexed column must drop the OLD index entry's
+-- primary key so a later seek of the OLD value yields no phantom row.
+--
+-- Pre-fix, MemoryIndexEntry.primaryKeys was a JS Set keyed by reference; a
+-- composite PK is a freshly-allocated array each extraction, so removeEntry
+-- could never drop it by value. The stale PK lingered in the OLD index entry
+-- and a `WHERE v = <old>` seek through that index surfaced the row even though
+-- its value had changed.
+--
+-- NOTE: whether this manifests end-to-end depends on the access planner
+-- routing the equality seek through the secondary index. If it full-scans the
+-- primary tree it would return the correct (empty) result regardless of the
+-- bug — the authoritative regression lives in
+-- test/vtab/memory-index-pk-value-identity.spec.ts at the MemoryIndex level.
+
+CREATE TABLE ci (a INTEGER, b INTEGER, v INTEGER, PRIMARY KEY (a, b));
+INSERT INTO ci VALUES (1, 1, 100), (1, 2, 200), (2, 1, 300);
+CREATE INDEX ci_v ON ci (v);
+
+-- Baseline: the indexed seek finds the right row before any update.
+SELECT a, b FROM ci WHERE v = 100;
+→ [{"a":1,"b":1}]
+
+-- Update the indexed column of the (1,1) row: 100 -> 999.
+UPDATE ci SET v = 999 WHERE a = 1 AND b = 1;
+
+-- Seek the OLD index value: must be empty (no phantom from a stale PK).
+SELECT a, b FROM ci WHERE v = 100;
+→ []
+
+-- The NEW value is findable, mapped to exactly the updated row.
+SELECT a, b FROM ci WHERE v = 999 ORDER BY a, b;
+→ [{"a":1,"b":1}]
+
+-- Untouched rows are unaffected.
+SELECT a, b FROM ci WHERE v = 200;
+→ [{"a":1,"b":2}]
+SELECT a, b FROM ci WHERE v = 300;
+→ [{"a":2,"b":1}]
+
+-- Delete a composite-PK row and confirm its index value drops out too.
+DELETE FROM ci WHERE a = 1 AND b = 2;
+SELECT a, b FROM ci WHERE v = 200;
+→ []
+
+-- Full ordered view: only the live rows remain.
+SELECT a, b, v FROM ci ORDER BY a, b;
+→ [{"a":1,"b":1,"v":999},{"a":2,"b":1,"v":300}]
+
+DROP TABLE ci;

package/test/logic/10.5.5-index-name-uniqueness.sqllogic

@@ -0,0 +1,76 @@
+-- 10.5.5-index-name-uniqueness.sqllogic
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Index names are unique per schema, not per table (docs/sql-vtab.md §6.3).
+-- DROP INDEX / ALTER INDEX / sync all resolve an index by name alone, so a
+-- duplicate name would resolve by table-registration order.
+
+CREATE TABLE iu_t1 (id INTEGER PRIMARY KEY, note TEXT);
+CREATE TABLE iu_t2 (id INTEGER PRIMARY KEY, note TEXT);
+
+CREATE INDEX idx_note ON iu_t1 (note);
+
+-- Same name, different table in the same schema: rejected, naming the owner.
+CREATE INDEX idx_note ON iu_t2 (note);
+-- error: Index 'idx_note' already exists in schema 'main' on table 'iu_t1'
+
+-- Case-divergent spelling collides too (index names compare case-insensitively).
+CREATE INDEX IDX_NOTE ON iu_t2 (note);
+-- error: already exists in schema 'main' on table 'iu_t1'
+
+-- IF NOT EXISTS does NOT suppress a cross-table collision: an index of that name
+-- on another table is a different object, and skipping would silently leave
+-- iu_t2 without the requested index.
+CREATE INDEX IF NOT EXISTS idx_note ON iu_t2 (note);
+-- error: Index 'idx_note' already exists in schema 'main' on table 'iu_t1'
+
+-- ...but IF NOT EXISTS still suppresses a same-table duplicate.
+CREATE INDEX IF NOT EXISTS idx_note ON iu_t1 (note);
+
+-- A UNIQUE index occupies the same namespace as a plain one.
+CREATE UNIQUE INDEX idx_note ON iu_t2 (note);
+-- error: Index 'idx_note' already exists in schema 'main' on table 'iu_t1'
+
+-- The owner is unambiguous, so DROP INDEX resolves without guessing.
+DROP INDEX idx_note;
+
+-- Freed name: the previously rejected statement now succeeds on iu_t2.
+CREATE INDEX idx_note ON iu_t2 (note);
+
+INSERT INTO iu_t2 VALUES (1, 'alpha'), (2, 'beta');
+SELECT id FROM iu_t2 WHERE note = 'beta';
+→ [{"id":2}]
+
+DROP INDEX idx_note;
+
+-- ========================================
+-- Implicit covering structures are NOT in the schema-wide namespace
+-- ========================================
+
+-- A plain UNIQUE constraint's auto-built covering structure takes the
+-- constraint's name, and constraint names are unique per TABLE. Two tables may
+-- each declare `constraint uq_email unique (email)`.
+CREATE TABLE iu_a (id INTEGER PRIMARY KEY, email TEXT, CONSTRAINT uq_email UNIQUE (email));
+CREATE TABLE iu_b (id INTEGER PRIMARY KEY, email TEXT, CONSTRAINT uq_email UNIQUE (email));
+
+-- Both constraints still enforce independently.
+INSERT INTO iu_a VALUES (1, 'x@example.com');
+INSERT INTO iu_b VALUES (1, 'x@example.com');
+
+SELECT count(*) AS n FROM iu_a;
+→ [{"n":1}]
+
+INSERT INTO iu_a VALUES (2, 'x@example.com');
+-- error: UNIQUE constraint
+
+-- An ordinary CREATE INDEX may take a name held only by another table's implicit
+-- covering structure — that structure is not a user object in the namespace.
+CREATE TABLE iu_c (id INTEGER PRIMARY KEY, email TEXT);
+CREATE INDEX uq_email ON iu_c (email);
+
+DROP TABLE iu_c;
+DROP TABLE iu_b;
+DROP TABLE iu_a;
+DROP TABLE iu_t2;
+DROP TABLE iu_t1;

package/test/logic/10.5.6-minmax-index-boundary.sqllogic

@@ -0,0 +1,204 @@
+-- 10.5.6-minmax-index-boundary.sqllogic — answers for the ungrouped MIN/MAX rewrite.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- The optimizer rewrites an ungrouped `min(c)` / `max(c)` over an indexed column into
+-- `min(c)` over `(… where c is not null order by c limit 1)`, keeping the aggregate
+-- itself on top. That is a plan-shape change only, so every answer below must be
+-- identical to what a full scan would produce — which is exactly what this file pins,
+-- on BOTH backends.
+--
+-- Plan-shape claims (which index is used, whether a LIMIT survives, work counters)
+-- are backend-dependent and live in test/optimizer/minmax-index-boundary.spec.ts.
+-- Keep them out of here.
+
+-- =====================================================
+-- 1. Empty relation — one row, NULL
+-- =====================================================
+-- The aggregate survives the rewrite, so an ungrouped aggregate over zero rows still
+-- emits exactly one row and min/max finalize an empty accumulator to NULL.
+create table mm_empty (k integer primary key, c integer);
+create index mm_empty_c on mm_empty(c);
+create index mm_empty_c_desc on mm_empty(c desc);
+
+select min(c) as v from mm_empty;
+→ [{"v":null}]
+
+select max(c) as v from mm_empty;
+→ [{"v":null}]
+
+select count(*) as n from mm_empty;
+→ [{"n":0}]
+
+drop table mm_empty;
+
+-- =====================================================
+-- 2. All-NULL column — one row, NULL
+-- =====================================================
+create table mm_null (k integer primary key, c integer null);
+create index mm_null_c on mm_null(c);
+create index mm_null_c_desc on mm_null(c desc);
+insert into mm_null values (1, null), (2, null), (3, null);
+
+select min(c) as v from mm_null;
+→ [{"v":null}]
+
+select max(c) as v from mm_null;
+→ [{"v":null}]
+
+drop table mm_null;
+
+-- =====================================================
+-- 3. NULLs at the boundary — the extreme NON-NULL value wins
+-- =====================================================
+-- ORDER BY in this engine places NULLs FIRST for both directions, so without the
+-- rewrite's `is not null` arm a `limit 1` would hand the aggregate a NULL. Both an
+-- ascending and a descending index are present so both directions take the rewrite.
+create table mm_mix (k integer primary key, c integer null);
+create index mm_mix_c on mm_mix(c);
+create index mm_mix_c_desc on mm_mix(c desc);
+insert into mm_mix values (1, 30), (2, null), (3, 10), (4, null), (5, 50), (6, 20);
+
+select min(c) as v from mm_mix;
+→ [{"v":10}]
+
+select max(c) as v from mm_mix;
+→ [{"v":50}]
+
+-- DISTINCT never changes an extremum.
+select min(distinct c) as v from mm_mix;
+→ [{"v":10}]
+
+select max(distinct c) as v from mm_mix;
+→ [{"v":50}]
+
+-- Only NULLs survive the WHERE, so the answer is NULL again.
+select max(c) as v from mm_mix where c is null;
+→ [{"v":null}]
+
+drop table mm_mix;
+
+-- =====================================================
+-- 4. WHERE clauses must not be lost
+-- =====================================================
+create table mm_w (k integer primary key, g integer, c integer);
+create index mm_w_gc on mm_w(g, c desc);
+create index mm_w_gc_asc on mm_w(g, c);
+insert into mm_w values (1, 1, 10), (2, 1, 40), (3, 2, 70), (4, 2, 20), (5, 1, 25);
+
+-- Equality-bound composite prefix: the index orders `c` within each `g`.
+select max(c) as v from mm_w where g = 1;
+→ [{"v":40}]
+
+select min(c) as v from mm_w where g = 2;
+→ [{"v":20}]
+
+-- Range predicate on the aggregated column itself.
+select max(c) as v from mm_w where c < 40;
+→ [{"v":25}]
+
+select min(c) as v from mm_w where c > 20;
+→ [{"v":25}]
+
+-- A WHERE that matches nothing still emits one NULL row.
+select max(c) as v from mm_w where g = 99;
+→ [{"v":null}]
+
+-- HAVING is a filter ABOVE the aggregate; unaffected by the rewrite.
+select max(c) as v from mm_w having max(c) > 5;
+→ [{"v":70}]
+
+select max(c) as v from mm_w having max(c) > 500;
+→ []
+
+drop table mm_w;
+
+-- =====================================================
+-- 5. Correlated MIN/MAX subquery
+-- =====================================================
+create table mm_o (g integer primary key);
+create table mm_i (k integer primary key, g integer, c integer);
+create index mm_i_gc on mm_i(g, c desc);
+insert into mm_o values (1), (2), (3);
+insert into mm_i values (1, 1, 10), (2, 1, 40), (3, 2, 70);
+
+select g, (select max(c) from mm_i where mm_i.g = mm_o.g) as m from mm_o order by g;
+→ [{"g":1,"m":40},{"g":2,"m":70},{"g":3,"m":null}]
+
+drop table mm_i;
+drop table mm_o;
+
+-- =====================================================
+-- 6. Comparator agreement — the rewrite must rank like the aggregate does
+-- =====================================================
+-- The rewrite never compares values itself: it delegates to the access plan's
+-- ordering claim, and min/max rank under the argument's semantic comparator. These
+-- two columns are where a drift between the two would show up first, because their
+-- ordering is NOT byte order.
+
+-- COLLATE NOCASE: 'A' < 'b' < 'C', not 'A' < 'C' < 'b'.
+create table mm_n (k integer primary key, n text collate nocase);
+create index mm_n_n on mm_n(n);
+create index mm_n_n_desc on mm_n(n desc);
+insert into mm_n values (1, 'b'), (2, 'A'), (3, 'C');
+
+select min(n) as v from mm_n;
+→ [{"v":"A"}]
+
+select max(n) as v from mm_n;
+→ [{"v":"C"}]
+
+drop table mm_n;
+
+-- TIMESPAN: 'PT30M' < 'PT1H' < 'P1D' by duration, not by text.
+create table mm_s (k integer primary key, s timespan);
+create index mm_s_s on mm_s(s);
+create index mm_s_s_desc on mm_s(s desc);
+insert into mm_s values (1, 'PT1H'), (2, 'PT30M'), (3, 'P1D');
+
+select min(s) as v from mm_s;
+→ [{"v":"PT30M"}]
+
+select max(s) as v from mm_s;
+→ [{"v":"P1D"}]
+
+drop table mm_s;
+
+-- =====================================================
+-- 7. Shapes the rewrite must decline — answers stay correct either way
+-- =====================================================
+create table mm_d (k integer primary key, g integer, c integer);
+create index mm_d_c on mm_d(c);
+create index mm_d_c_desc on mm_d(c desc);
+insert into mm_d values (1, 1, 10), (2, 1, 40), (3, 2, 70), (4, 2, 20);
+
+-- Both ends of the index at once.
+select min(c) as lo, max(c) as hi from mm_d;
+→ [{"lo":10,"hi":70}]
+
+-- count(*) genuinely needs every row — truncating the source would return 1.
+select max(c) as v, count(*) as n from mm_d;
+→ [{"v":70,"n":4}]
+
+-- GROUP BY present.
+select g, max(c) as v from mm_d group by g order by g;
+→ [{"g":1,"v":40},{"g":2,"v":70}]
+
+-- A non-trivial argument.
+select max(c + 1) as v from mm_d;
+→ [{"v":71}]
+
+-- A derived table between the aggregate and the base table.
+select max(c) as v from (select c from mm_d) x;
+→ [{"v":70}]
+
+-- A primary-key range the module may prefer over the `c` ordering. Whether the
+-- boundary read or a full scan wins is a module cost decision (and differs by
+-- backend); the answer must not be.
+select max(c) as v from mm_d where k > 1;
+→ [{"v":70}]
+
+select min(c) as v from mm_d where k > 1;
+→ [{"v":20}]
+
+drop table mm_d;