@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/01.9-query-expr-values.sqllogic

@@ -0,0 +1,111 @@
+-- query-expr-values.sqllogic — exercises the unified QueryExpr surface for
+-- VALUES bodies at every relation site. These cases parse + execute under
+-- the pure-VALUES portion of the orthogonality work; DML-as-relation cases
+-- are gated until the follow-up dml-in-expression-position ticket lifts them.
+
+-- ===================================
+-- 1. VALUES as a CTE body (was a parser TODO; now first-class)
+-- ===================================
+
+with t(a, b) as (values (1, 'x'), (2, 'y'))
+select a, b from t order by a;
+→ [{"a":1,"b":"x"},{"a":2,"b":"y"}]
+
+-- ===================================
+-- 2. VALUES as a compound-set leg (UNION ALL with another VALUES)
+-- ===================================
+
+values (1) union all values (2);
+→ [{"column_0":1},{"column_0":2}]
+
+-- ===================================
+-- 3. Mixed compound: SELECT against a subquery VALUES, then UNION ALL with VALUES
+-- ===================================
+-- Output column names follow the union output naming convention used by the
+-- planner today; what we're pinning here is that the rows survive
+-- end-to-end through the unified compound-leg parser.
+
+select * from (values (1, 'x'), (2, 'y')) as t(a, b)
+union all
+values (3, 'z');
+→ [{"column_0":1,"column_1":"x"},{"column_0":2,"column_1":"y"},{"column_0":3,"column_1":"z"}]
+
+-- ===================================
+-- 4. VALUES as a CREATE VIEW body — names synthesized from the body
+-- ===================================
+
+create view v_unnamed as values (1, 'a'), (2, 'b');
+select * from v_unnamed order by column_0;
+→ [{"column_0":1,"column_1":"a"},{"column_0":2,"column_1":"b"}]
+drop view v_unnamed;
+
+-- ===================================
+-- 5. VALUES as a CREATE VIEW body — binding-site column names win
+-- ===================================
+
+create view v_named(a, b) as values (1, 'x'), (2, 'y');
+select * from v_named order by a;
+→ [{"a":1,"b":"x"},{"a":2,"b":"y"}]
+drop view v_named;
+
+-- ===================================
+-- 6. VALUES inside IN (already worked via Project(Values…); pinned here)
+-- ===================================
+
+select 2 in (values (1), (2), (3)) as found;
+→ [{"found":true}]
+
+-- ===================================
+-- 7. VALUES inside EXISTS
+-- ===================================
+
+select exists (values (1)) as ex;
+→ [{"ex":true}]
+
+-- ===================================
+-- 8. Scalar / row subquery with VALUES body
+-- ===================================
+
+select (values (42)) as v;
+→ [{"v":42}]
+
+-- ===================================
+-- 9. Three-leg compound chain of bare VALUES
+-- ===================================
+-- The right leg of a compound recurses through the VALUES wrapper so chains
+-- longer than two legs work, not just `VALUES … UNION VALUES …`.
+
+values (1) union all values (2) union all values (3);
+→ [{"column_0":1},{"column_0":2},{"column_0":3}]
+
+-- ===================================
+-- 10. Bare VALUES + ORDER BY at top level (no compound)
+-- ===================================
+-- The wrapper synthesizes whenever ORDER BY / LIMIT / OFFSET follow VALUES,
+-- not just on compound. Result column names come from the inner VALUES
+-- (synthetic `column_0`).
+
+values (3), (1), (2) order by column_0;
+→ [{"column_0":1},{"column_0":2},{"column_0":3}]
+
+-- ===================================
+-- 11. Bare VALUES + LIMIT/OFFSET at top level
+-- ===================================
+
+values (1), (2), (3), (4) limit 2 offset 1;
+→ [{"column_0":2},{"column_0":3}]
+
+-- ===================================
+-- 12. Bare VALUES + ORDER BY/LIMIT inside a parenthesized subquery source
+-- ===================================
+
+select * from (values (3), (1), (2) order by column_0 limit 2) as v;
+→ [{"column_0":1},{"column_0":2}]
+
+-- ===================================
+-- 13. Bare VALUES + ORDER BY in a CTE body
+-- ===================================
+
+with c(a) as (values (3), (1), (2) order by column_0)
+select a from c;
+→ [{"a":1},{"a":2},{"a":3}]

package/test/logic/01.9.1-limit-over-dml-subquery.sqllogic

@@ -0,0 +1,119 @@
+-- 01.9.1-limit-over-dml-subquery.sqllogic - a LIMIT never truncates a writing source
+--
+-- `select ... from (insert/update/delete ... returning ...) limit n` caps what the
+-- QUERY returns, not what the STATEMENT writes: the data-modifying subquery runs to
+-- completion and the LIMIT only decides how many of its RETURNING rows come back.
+--
+-- The LIMIT arm of 01.9-query-expr-dml.sqllogic, which pins the same full-drain rule for
+-- a writing inner in scalar / IN / EXISTS / CTE-body / FROM-source position. It is also
+-- the rule 13.6 pins for a data-modifying CTE under `limit 0`, and the answer PostgreSQL
+-- gives for a data-modifying CTE. Before bug-limit-reads-one-row-too-many this case gave
+-- a third answer — it wrote exactly one row more than it returned, an artifact of the
+-- LIMIT reading one row past its last emitted one.
+--
+-- Scope: "runs to completion" means when the statement itself is run to completion.
+-- Abandoning the result iteration early stops the writes with it, exactly as it does for
+-- a DML FROM-subquery with no LIMIT at all — see docs/sql-select.md § Query expressions.
+--
+-- Every section asserts BOTH halves: the rows the query returned, and the rows that
+-- landed in the target table.
+
+-- ===== INSERT ... RETURNING under LIMIT 1 =====
+
+create table srcq (k integer primary key);
+insert into srcq values (1), (2), (3), (4);
+create table d1 (k integer primary key);
+-- run
+
+select k from (insert into d1 select k from srcq returning k) limit 1;
+→ [{"k":1}]
+
+-- All four rows written, not one and not two.
+select count(*) as n from d1;
+→ [{"n":4}]
+
+-- ===== INSERT ... RETURNING under LIMIT 0 =====
+-- The strongest form: the query consumes nothing at all and the write still happens.
+
+create table d2 (k integer primary key);
+-- run
+
+select k from (insert into d2 select k from srcq returning k) limit 0;
+→ []
+
+select count(*) as n from d2;
+→ [{"n":4}]
+
+-- ===== INSERT ... RETURNING under LIMIT with OFFSET =====
+
+create table d3 (k integer primary key);
+-- run
+
+select k from (insert into d3 select k from srcq returning k) limit 2 offset 1;
+→ [{"k":2},{"k":3}]
+
+select count(*) as n from d3;
+→ [{"n":4}]
+
+-- ===== UPDATE ... RETURNING under LIMIT 1 =====
+-- The silent-corruption shape: a partial update looks plausible in the output.
+
+create table uq (k integer primary key, v integer);
+insert into uq values (1, 0), (2, 0), (3, 0), (4, 0);
+-- run
+
+select k from (update uq set v = v + 1 returning k, v) limit 1;
+→ [{"k":1}]
+
+-- Every row incremented, not just the one the LIMIT let through.
+select k, v from uq order by k;
+→ [{"k":1,"v":1},{"k":2,"v":1},{"k":3,"v":1},{"k":4,"v":1}]
+
+-- ===== DELETE ... RETURNING under LIMIT 1 =====
+
+create table xq (k integer primary key);
+insert into xq values (1), (2), (3), (4);
+-- run
+
+select k from (delete from xq where k >= 2 returning k) limit 1;
+→ [{"k":2}]
+
+-- All three matching rows deleted, not just the returned one.
+select k from xq order by k;
+→ [{"k":1}]
+
+-- ===== Control: a read-only source IS truncated by the LIMIT =====
+-- The drain rule is scoped to writing sources. A pure subquery still stops early —
+-- that is the whole point of a LIMIT. (Row-level "stopped early, did not over-read"
+-- counts are pinned in test/runtime/early-stop-consumption.spec.ts.)
+
+select k from (select k from srcq) order by k limit 1;
+→ [{"k":1}]
+
+select count(*) as n from srcq;
+→ [{"n":4}]
+
+-- ===== A LIMIT above another LIMIT still drains =====
+-- The drain gate asks whether the WHOLE subtree writes, not whether the immediate child
+-- does, so an outer LIMIT over an inner LIMIT over a DML drains through both. Pinned
+-- because narrowing the gate to "my direct child is a mutation" would silently
+-- reintroduce the truncation one level up.
+
+create table d4 (k integer primary key);
+-- run
+
+select k from (select k from (insert into d4 select k from srcq returning k) limit 3) limit 1;
+→ [{"k":1}]
+
+select count(*) as n from d4;
+→ [{"n":4}]
+
+-- Cleanup
+drop table srcq;
+drop table d4;
+drop table d1;
+drop table d2;
+drop table d3;
+drop table uq;
+drop table xq;
+-- run

package/test/logic/02-filters.sqllogic

@@ -0,0 +1,54 @@
+-- 02-filters.sqllogic — Behavioural regression for WHERE-clause optimizer rules.
+-- Initial focus: rulePredicateInferenceEquivalence (EC × constant binding → inferred eq).
+
+-- ---------------------------------------------------------------------------
+-- Predicate inference (EC × constant binding) — semantic equivalence.
+-- ---------------------------------------------------------------------------
+
+create table t (k int primary key, v text);
+create table u (k int primary key, v text);
+
+insert into t values (1, 'a'), (5, 'e'), (10, 'j');
+insert into u values (5, 'E'), (7, 'G'), (10, 'J');
+
+-- Literal: inference should produce u.k = 5 on the u-side; result is the
+-- single matched row.
+select t.v as tv, u.v as uv from t join u on t.k = u.k where t.k = 5;
+→ [{"tv":"e","uv":"E"}]
+
+-- Parameter: inference threads the same parameter through to the u-side
+-- access path. Result must match the literal form for the same value.
+-- params: [10]
+select t.v as tv, u.v as uv from t join u on t.k = u.k where t.k = ?;
+→ [{"tv":"j","uv":"J"}]
+
+-- LEFT JOIN safety: outer's t.k = 5 must NOT propagate to the right side as
+-- an EC-derived restriction (that would prune null-padded rows). Unmatched
+-- left rows survive with NULL on the right.
+select t.k as tk, u.k as uk from t left join u on t.k = u.k where t.k <= 5 order by t.k;
+→ [{"tk":1,"uk":null},{"tk":5,"uk":5}]
+
+-- Multi-hop chain: a.x = 7 should propagate through both equi-joins so the
+-- chain returns rows only when every joined side has x = 7.
+create table ta (id int primary key, x int);
+create table tb (id int primary key, x int);
+create table tc (id int primary key, x int);
+
+insert into ta values (1, 7), (2, 8);
+insert into tb values (1, 7), (2, 8);
+insert into tc values (1, 7), (2, 8);
+
+select ta.x as ax, tb.x as bx, tc.x as cx
+  from ta join tb on ta.x = tb.x
+          join tc on tb.x = tc.x
+ where ta.x = 7;
+→ [{"ax":7,"bx":7,"cx":7}]
+
+drop table tc;
+drop table tb;
+drop table ta;
+drop table u;
+
+-- Prefix-NOT precedence (issue #22) is covered by the full predicate
+-- matrix in 03.8-not-precedence.sqllogic.
+drop table t;

package/test/logic/02-smoke.sqllogic

@@ -0,0 +1,62 @@
+-- smoke.sqllogic - Basic sanity checks for core operations
+
+-- Test basic operations
+
+-- Set default VTab for subsequent CREATE TABLE
+-- Create a table
+CREATE TABLE t1(a INTEGER PRIMARY KEY, b TEXT);
+--SELECT name FROM schema() WHERE type = 'table' AND name = 't1';
+--→ [{"name":"t1"}]
+
+-- Insert some rows
+INSERT INTO t1 VALUES (1, 'one');
+INSERT INTO t1 (a, b) VALUES (2, 'two');
+--SELECT count(*) FROM t1;
+--→ [{"count(*)": 2}]
+
+-- Select data with ordering
+--SELECT * FROM t1 ORDER BY a;
+--→ [{"a":1,"b":"one"},{"a":2,"b":"two"}]
+
+-- Select specific columns
+--SELECT b FROM t1 WHERE a = 1;
+--→ [{"b":"one"}]
+
+-- Update data
+UPDATE t1 SET b = 'deux' WHERE a = 2;
+--SELECT b FROM t1 WHERE a = 2;
+--→ [{"b":"deux"}]
+SELECT * FROM t1 ORDER BY a;
+→ [{"a":1,"b":"one"},{"a":2,"b":"deux"}]
+
+-- Delete data
+DELETE FROM t1 WHERE a = 1;
+SELECT count(*) FROM t1;
+→ [{"count(*)": 1}]
+SELECT * FROM t1;
+→ [{"a":2,"b":"deux"}]
+
+-- Block 1: Drop the table
+DROP TABLE t1;
+-- No expected output for DROP
+
+-- Block 2: Verify table is gone
+SELECT name FROM schema() WHERE type = 'table' AND name = 't1';
+→ []
+
+-- Test NULL handling (column val explicitly nullable for NULL testing)
+CREATE TABLE t_null(id INTEGER PRIMARY KEY, val NUMERIC NULL);
+INSERT INTO t_null VALUES (1, NULL), (2, 10), (3, 20.5);
+SELECT * FROM t_null ORDER BY id;
+→ [{"id":1,"val":null},{"id":2,"val":10},{"id":3,"val":20.5}]
+DROP TABLE t_null;
+
+-- Test updating NULL column to non-NULL value (regression test)
+CREATE TABLE items (id TEXT PRIMARY KEY, name TEXT, description TEXT NULL);
+INSERT INTO items (id, name, description) VALUES ('item-1', 'Coffee', null);
+SELECT description FROM items WHERE id = 'item-1';
+→ [{"description":null}]
+UPDATE items SET description = 'dddd' WHERE id = 'item-1';
+SELECT description FROM items WHERE id = 'item-1';
+→ [{"description":"dddd"}]
+DROP TABLE items;

package/test/logic/02.1-bind-parameters.sqllogic

@@ -0,0 +1,223 @@
+-- adapted from SQLite test/bind.test
+-- Bind parameter syntax and binding semantics across statement types.
+-- Quereus parameter forms: `?` (positional), `:name`, `:N` (numeric named),
+-- `$name`, `$N` (numeric named).  `@name` and `?N` are NOT supported.
+
+create table bp (id integer primary key, val integer null, name text);
+insert into bp values (1, 10, 'alpha'), (2, 20, 'beta'), (3, 30, 'gamma'), (4, null, 'delta');
+
+-- ===================================
+-- Positional `?` in basic SELECT
+-- ===================================
+
+-- params: [1]
+select val from bp where id = ?;
+→ [{"val":10}]
+
+-- Two positional parameters, both bound from one params array
+-- params: [1, 25]
+select id from bp where id = ? or val > ?;
+→ [{"id":1},{"id":3}]
+
+-- ===================================
+-- Named `:name` in basic SELECT
+-- ===================================
+
+-- params: {"id": 2}
+select val from bp where id = :id;
+→ [{"val":20}]
+
+-- params: {"min": 15, "name": "gamma"}
+select id from bp where val >= :min and name = :name;
+→ [{"id":3}]
+
+-- Same named parameter referenced twice
+-- params: {"target": 2}
+select id from bp where id = :target or id = :target + 1;
+→ [{"id":2},{"id":3}]
+
+-- ===================================
+-- Named `$name` in basic SELECT
+-- ===================================
+
+-- params: {"id": 3}
+select val from bp where id = $id;
+→ [{"val":30}]
+
+-- ===================================
+-- Numeric named `:N` and `$N`
+-- ===================================
+
+-- params: {"1": 1}
+select val from bp where id = :1;
+→ [{"val":10}]
+
+-- params: {"1": 2}
+select val from bp where id = $1;
+→ [{"val":20}]
+
+-- ===================================
+-- Parameter type variation
+-- ===================================
+
+-- Integer
+-- params: [10]
+select id from bp where val = ?;
+→ [{"id":1}]
+
+-- Real
+-- params: [20.0]
+select id from bp where val = ?;
+→ [{"id":2}]
+
+-- Text
+-- params: ["alpha"]
+select id from bp where name = ?;
+→ [{"id":1}]
+
+-- NULL
+-- IS-as-equality (val IS ?) is SQLite-only; Quereus restricts IS to IS NULL/IS NOT NULL.
+-- Use explicit null check instead.
+-- params: []
+select id from bp where val is null;
+→ [{"id":4}]
+
+-- ===================================
+-- Parameter in INSERT / UPDATE / DELETE
+-- ===================================
+
+-- params: [5, 50, "epsilon"]
+insert into bp (id, val, name) values (?, ?, ?);
+→ []
+
+select val, name from bp where id = 5;
+→ [{"val":50,"name":"epsilon"}]
+
+-- params: [99, 5]
+update bp set val = ? where id = ?;
+→ []
+
+select val from bp where id = 5;
+→ [{"val":99}]
+
+-- params: [5]
+delete from bp where id = ?;
+→ []
+
+select count(*) as cnt from bp where id = 5;
+→ [{"cnt":0}]
+
+-- ===================================
+-- Parameter in expression contexts
+-- ===================================
+
+-- Arithmetic — text-order binding.
+-- Positional `?` bind in SOURCE-TEXT order, NOT plan/resolution order. Here the
+-- projection `?` (first in the text) takes 100 and the WHERE `?` (second) takes 1,
+-- so we boost row id=1 (val 10) by 100. Under the OLD plan-order behaviour the
+-- WHERE `?` would have bound first (=100, no such id) yielding []; this case pins
+-- the text-order contract.
+-- params: [100, 1]
+select val + ? as boosted from bp where id = ?;
+→ [{"boosted":110}]
+
+-- Discriminator — a projection `?` AND a WHERE `?` whose values differ, so the two
+-- binding orders give visibly different results. Text order: projection `?`=7,
+-- WHERE `?`=2 → boost row id=2 (val 20) → 27. Plan order would bind WHERE first
+-- (=7, no row) → [].
+-- params: [7, 2]
+select val + ? as boosted from bp where id = ?;
+→ [{"boosted":27}]
+
+-- Projection `?` mixed with a FROM/WHERE `in (?, ?)` — mirrors the codec import/
+-- export shape (a TVF/aggregate projection arg preceding WHERE-list args). Text
+-- order: tag `?`='T', then the in-list `?`s = 1, 3.
+-- params: ["T", 1, 3]
+select ? as tag, id from bp where id in (?, ?) order by id;
+→ [{"tag":"T","id":1},{"tag":"T","id":3}]
+
+-- Function call
+-- params: ["alp"]
+select id from bp where name like ? || '%';
+→ [{"id":1}]
+
+-- CASE expression
+-- params: [2]
+select case when id = ? then 'match' else 'miss' end as r from bp order by id;
+→ [{"r":"miss"},{"r":"match"},{"r":"miss"},{"r":"miss"}]
+
+-- IN list with multiple parameters
+-- params: [1, 3]
+select id from bp where id in (?, ?) order by id;
+→ [{"id":1},{"id":3}]
+
+-- ===================================
+-- Single-placeholder IN over the PK
+-- ===================================
+-- Regression: `col in (?)` with exactly one placeholder over an indexed/PK column
+-- reduced to a point-seek on Literal(undefined) and degraded to a full-index walk,
+-- so the predicate silently matched (and, for DELETE, wiped) every row. It must
+-- match exactly the bound row. See quereus-single-element-in-list-matches-all.
+
+-- params: [2]
+select id from bp where id in (?) order by id;
+→ [{"id":2}]
+
+-- Re-bound with a different value (the placeholder must not be constant-folded)
+-- params: [3]
+select id from bp where id in (?) order by id;
+→ [{"id":3}]
+
+-- One-, two-, three-placeholder IN and `= ?` agree on the bound rows
+-- params: [1]
+select id from bp where id = ? order by id;
+→ [{"id":1}]
+
+-- params: [1, 4]
+select id from bp where id in (?, ?) order by id;
+→ [{"id":1},{"id":4}]
+
+-- params: [1, 2, 4]
+select id from bp where id in (?, ?, ?) order by id;
+→ [{"id":1},{"id":2},{"id":4}]
+
+-- A non-matching single placeholder matches nothing (not everything)
+-- params: [99]
+select id from bp where id in (?) order by id;
+→ []
+
+-- ===================================
+-- Parameter in LIMIT / OFFSET
+-- ===================================
+
+-- params: [2]
+select id from bp order by id limit ?;
+→ [{"id":1},{"id":2}]
+
+-- params: [2, 1]
+select id from bp order by id limit ? offset ?;
+→ [{"id":2},{"id":3}]
+
+-- ===================================
+-- Repeated execution with different parameter values
+-- ===================================
+-- Same prepared shape, different bind values — verifies parameters are
+-- not constant-folded into the plan.
+
+-- params: [1]
+select val from bp where id = ?;
+→ [{"val":10}]
+
+-- params: [2]
+select val from bp where id = ?;
+→ [{"val":20}]
+
+-- params: [99]
+select val from bp where id = ?;
+→ []
+
+-- ===================================
+-- Cleanup
+-- ===================================
+
+drop table bp;