@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/06.4-schema-search-path.sqllogic

@@ -0,0 +1,354 @@
+-- Schema Search Path Tests
+-- Tests for WITH SCHEMA clause and PRAGMA schema_path
+
+-- Setup: Create tables in main schema
+CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
+INSERT INTO users VALUES (1, 'Alice'), (2, 'Bob');
+
+CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, amount REAL);
+INSERT INTO orders VALUES (1, 1, 100.50), (2, 2, 200.75);
+
+-- Test 1: Default behavior - unqualified names resolve to main
+SELECT * FROM users ORDER BY id;
+→ [{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]
+
+-- Test 2: WITH SCHEMA clause with main (should work)
+SELECT * FROM users WITH SCHEMA main ORDER BY id;
+→ [{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]
+
+-- Test 3: WITH SCHEMA on JOIN queries
+SELECT u.id, u.name, o.id as order_id, o.amount FROM users u JOIN orders o ON u.id = o.user_id WITH SCHEMA main ORDER BY u.id;
+→ [{"id":1,"name":"Alice","order_id":1,"amount":100.5},{"id":2,"name":"Bob","order_id":2,"amount":200.75}]
+
+-- Test 4: PRAGMA schema_path - set and query
+PRAGMA schema_path = 'main';
+
+PRAGMA schema_path;
+→ [{"name":"schema_path","value":"main"}]
+
+-- Test 5: After setting pragma, unqualified names still work
+SELECT * FROM users ORDER BY id;
+→ [{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]
+
+-- Test 6: INSERT with WITH SCHEMA
+INSERT INTO users (id, name) VALUES (3, 'Charlie') WITH SCHEMA main;
+
+SELECT * FROM users WHERE id = 3;
+→ [{"id":3,"name":"Charlie"}]
+
+-- Test 7: UPDATE with WITH SCHEMA
+UPDATE users SET name = 'Alice Updated' WHERE id = 1 WITH SCHEMA main;
+
+SELECT name FROM users WHERE id = 1;
+→ [{"name":"Alice Updated"}]
+
+-- Test 8: DELETE with WITH SCHEMA
+DELETE FROM users WHERE id = 3 WITH SCHEMA main;
+
+SELECT COUNT(*) as count FROM users;
+→ [{"count":2}]
+
+-- Test 9: WITH SCHEMA with CTEs
+WITH active_users AS (SELECT * FROM users WHERE id <= 2) SELECT * FROM active_users WITH SCHEMA main ORDER BY id;
+→ [{"id":1,"name":"Alice Updated"},{"id":2,"name":"Bob"}]
+
+-- Test 10: RETURNING with WITH SCHEMA
+INSERT INTO users (id, name) VALUES (4, 'David') WITH SCHEMA main RETURNING id, name;
+→ [{"id":4,"name":"David"}]
+
+-- Test 11: Multiple table references with different schemas via WITH SCHEMA
+SELECT u.name, o.amount, o.id as oid FROM users u JOIN orders o ON u.id = o.user_id WITH SCHEMA main ORDER BY o.id;
+→ [{"name":"Alice Updated","amount":100.5,"oid":1},{"name":"Bob","amount":200.75,"oid":2}]
+
+-- Test 12: Subqueries work with WITH SCHEMA
+SELECT * FROM (SELECT * FROM users WHERE id > 0) sub WITH SCHEMA main ORDER BY id;
+→ [{"id":1,"name":"Alice Updated"},{"id":2,"name":"Bob"},{"id":4,"name":"David"}]
+
+-- Test 13: WITH SCHEMA and WITH CONTEXT can appear in any order
+-- Note: We'd need mutation context tables to fully test this, but we can verify parsing
+
+-- ===================================
+-- Non-default schema: DML with WITH SCHEMA
+-- Tests that INSERT/UPDATE/DELETE properly propagate schema path context
+-- ===================================
+
+-- Create a custom schema with tables
+declare schema myapp {
+	table products {
+		id INTEGER PRIMARY KEY,
+		name TEXT NOT NULL,
+		status TEXT DEFAULT 'active'
+	}
+}
+
+apply schema myapp;
+
+-- run
+
+-- Seed data via explicit schema qualification (baseline, no bug)
+INSERT INTO myapp.products (id, name) VALUES (1, 'Widget');
+
+SELECT * FROM myapp.products;
+→ [{"id":1,"name":"Widget","status":"active"}]
+
+-- Test 14: UPDATE with WITH SCHEMA on non-default schema (update.ts:68 bug)
+-- The source scan must use contextWithSchemaPath to resolve the unqualified table name
+UPDATE products SET name = 'Gadget' WHERE id = 1 WITH SCHEMA myapp;
+
+SELECT * FROM myapp.products WHERE id = 1;
+→ [{"id":1,"name":"Gadget","status":"active"}]
+
+-- Test 15: INSERT with WITH SCHEMA on non-default schema (insert.ts:528 bug)
+-- Row expansion (default value computation) must use contextWithSchemaPath
+INSERT INTO products (id, name) VALUES (2, 'Doohickey') WITH SCHEMA myapp;
+
+SELECT * FROM myapp.products ORDER BY id;
+→ [{"id":1,"name":"Gadget","status":"active"},{"id":2,"name":"Doohickey","status":"active"}]
+
+-- Test 16: DELETE with WITH SCHEMA on non-default schema (verify parity with delete.ts)
+DELETE FROM products WHERE id = 2 WITH SCHEMA myapp;
+
+SELECT COUNT(*) as count FROM myapp.products;
+→ [{"count":1}]
+
+-- Test 17: INSERT with WITH SCHEMA + RETURNING on non-default schema
+INSERT INTO products (id, name) VALUES (3, 'Thingamajig') WITH SCHEMA myapp RETURNING id, name, status;
+→ [{"id":3,"name":"Thingamajig","status":"active"}]
+
+-- Test 17a: a SUBQUERY inside RETURNING also resolves on the statement's schema path.
+-- INSERT used to build RETURNING against the bare context, so an unqualified name in a
+-- RETURNING subquery ignored WITH SCHEMA and reported "not found in schema path: main"
+-- (UPDATE and DELETE already resolved it). `lookup` exists only in myapp, and is not
+-- touched by the insert, so the count is stable.
+CREATE TABLE myapp.lookup (k INTEGER PRIMARY KEY);
+INSERT INTO myapp.lookup VALUES (1), (2), (3);
+
+INSERT INTO products (id, name) VALUES (5, 'Whatsit') WITH SCHEMA myapp
+  RETURNING id, (SELECT COUNT(*) FROM lookup) AS n;
+→ [{"id":5,"n":3}]
+
+DELETE FROM myapp.products WHERE id = 5;
+
+-- Test 17b: the ON CONFLICT arm resolves the schema path too, and now EXECUTEs a
+-- subquery in that position: `DmlExecutorNode` exposes its ON CONFLICT expressions as
+-- optimizer-visible children, so their subquery subtrees get rewritten. Fixed by
+-- `bug-dml-side-expressions-invisible-to-optimizer`.
+INSERT INTO products (id, name) VALUES (3, 'Dupe')
+  ON CONFLICT (id) DO UPDATE SET name = (SELECT COUNT(*) FROM lookup)
+  WITH SCHEMA myapp RETURNING name;
+→ [{"name":"3"}]
+
+DROP TABLE myapp.lookup;
+
+-- ===================================
+-- Non-default schema: write-through a view whose home schema is not on the path
+-- The stored body's unqualified `products` must resolve next to the VIEW (myapp),
+-- for the write exactly as for the read — the session path here is 'main'.
+-- ===================================
+
+-- Test 18: INSERT / UPDATE / DELETE through a view stored in myapp
+CREATE VIEW myapp.product_names AS SELECT id, name FROM products;
+
+INSERT INTO myapp.product_names (id, name) VALUES (4, 'Gizmo');
+
+SELECT id, name, status FROM myapp.products WHERE id = 4;
+→ [{"id":4,"name":"Gizmo","status":"active"}]
+
+UPDATE myapp.product_names SET name = 'Gizmo II' WHERE id = 4;
+
+SELECT id, name FROM myapp.products WHERE id = 4;
+→ [{"id":4,"name":"Gizmo II"}]
+
+DELETE FROM myapp.product_names WHERE id = 4;
+
+SELECT COUNT(*) as count FROM myapp.products WHERE id = 4;
+→ [{"count":0}]
+
+-- Test 19: on a name collision the view's home schema wins over the session path
+CREATE TABLE products (id INTEGER PRIMARY KEY, name TEXT);
+INSERT INTO products (id, name) VALUES (9, 'main-row');
+
+UPDATE myapp.product_names SET name = 'via-view' WHERE id = 3;
+
+SELECT id, name FROM myapp.products WHERE id = 3;
+→ [{"id":3,"name":"via-view"}]
+
+SELECT id, name FROM main.products;
+→ [{"id":9,"name":"main-row"}]
+
+DROP TABLE products;
+DROP VIEW myapp.product_names;
+
+-- Clean up custom schema
+DROP TABLE myapp.products;
+
+-- Clean up
+DROP TABLE users;
+DROP TABLE orders;
+
+-- ===================================
+-- Unqualified VIEW names resolve through the schema search path, exactly as
+-- unqualified table names do (bug-unqualified-view-name-ignores-schema-path).
+-- ===================================
+
+CREATE TABLE temp.rt (id INTEGER PRIMARY KEY, x INTEGER);
+INSERT INTO temp.rt VALUES (1, 10);
+CREATE VIEW temp.rv AS SELECT id, x FROM rt;
+
+-- Test 20: qualified reference (baseline, never depended on the path)
+SELECT * FROM temp.rv;
+→ [{"id":1,"x":10}]
+
+-- Test 21: with `temp` OFF the session path an unqualified view is not found —
+-- the same answer an unqualified table in `temp` gets, hint included
+PRAGMA schema_path = 'main';
+
+SELECT * FROM rv;
+-- error: Did you mean: temp.rv?
+
+SELECT * FROM rt;
+-- error: Did you mean: temp.rt?
+
+-- Test 22: with `temp` ON the path both resolve
+PRAGMA schema_path = 'temp,main';
+
+SELECT * FROM rv;
+→ [{"id":1,"x":10}]
+
+SELECT * FROM rt;
+→ [{"id":1,"x":10}]
+
+-- Test 23: a view composed over another view in the same non-main schema
+CREATE VIEW temp.rv2 AS SELECT id, x FROM rv;
+
+SELECT * FROM temp.rv2;
+→ [{"id":1,"x":10}]
+
+SELECT * FROM rv2;
+→ [{"id":1,"x":10}]
+
+-- Test 24: unqualified INSERT / UPDATE / DELETE through a non-main view
+INSERT INTO rv (id, x) VALUES (2, 20);
+
+SELECT id, x FROM temp.rt ORDER BY id;
+→ [{"id":1,"x":10},{"id":2,"x":20}]
+
+UPDATE rv SET x = 21 WHERE id = 2;
+
+SELECT id, x FROM temp.rt WHERE id = 2;
+→ [{"id":2,"x":21}]
+
+DELETE FROM rv WHERE id = 2;
+
+SELECT COUNT(*) as count FROM temp.rt;
+→ [{"count":1}]
+
+-- Test 25: statement-level WITH SCHEMA reaches the view too
+-- (`temp` is a keyword in the WITH SCHEMA position, hence the quoted form)
+PRAGMA schema_path = 'main';
+
+SELECT id, x FROM rv WITH SCHEMA "temp";
+→ [{"id":1,"x":10}]
+
+UPDATE rv SET x = 12 WHERE id = 1 WITH SCHEMA "temp";
+
+SELECT id, x FROM temp.rt WHERE id = 1;
+→ [{"id":1,"x":12}]
+
+UPDATE temp.rv SET x = 10 WHERE id = 1;
+
+DROP VIEW temp.rv2;
+DROP VIEW temp.rv;
+DROP TABLE temp.rt;
+
+-- Test 26: within-path ordering — a TABLE in an earlier entry beats a VIEW of
+-- the same name in a later one, and vice versa. (A table/view collision inside
+-- ONE schema is impossible; CREATE TABLE / CREATE VIEW reject it.)
+CREATE TABLE main.dual_name (id INTEGER PRIMARY KEY, tag TEXT);
+INSERT INTO main.dual_name VALUES (1, 'table-in-main');
+CREATE TABLE temp.dn_src (id INTEGER PRIMARY KEY, tag TEXT);
+INSERT INTO temp.dn_src VALUES (1, 'view-in-temp');
+CREATE VIEW temp.dual_name AS SELECT id, tag FROM dn_src;
+
+PRAGMA schema_path = 'main,temp';
+
+SELECT tag FROM dual_name;
+→ [{"tag":"table-in-main"}]
+
+PRAGMA schema_path = 'temp,main';
+
+SELECT tag FROM dual_name;
+→ [{"tag":"view-in-temp"}]
+
+-- a qualified reference is unaffected by the path either way
+SELECT tag FROM main.dual_name;
+→ [{"tag":"table-in-main"}]
+
+SELECT tag FROM temp.dual_name;
+→ [{"tag":"view-in-temp"}]
+
+-- Test 27: the same ordering governs a WRITE target, not just a read
+CREATE TABLE temp.dn_w_src (id INTEGER PRIMARY KEY, tag TEXT);
+INSERT INTO temp.dn_w_src VALUES (1, 'view-in-temp');
+CREATE VIEW temp.dn_w AS SELECT id, tag FROM dn_w_src;
+CREATE TABLE main.dn_w (id INTEGER PRIMARY KEY, tag TEXT);
+INSERT INTO main.dn_w VALUES (1, 'table-in-main');
+
+PRAGMA schema_path = 'main,temp';
+
+UPDATE dn_w SET tag = 'wrote-main' WHERE id = 1;
+
+SELECT tag FROM main.dn_w;
+→ [{"tag":"wrote-main"}]
+
+SELECT tag FROM temp.dn_w_src;
+→ [{"tag":"view-in-temp"}]
+
+PRAGMA schema_path = 'temp,main';
+
+UPDATE dn_w SET tag = 'wrote-temp-view' WHERE id = 1;
+
+SELECT tag FROM main.dn_w;
+→ [{"tag":"wrote-main"}]
+
+SELECT tag FROM temp.dn_w_src;
+→ [{"tag":"wrote-temp-view"}]
+
+PRAGMA schema_path = 'main';
+
+DROP VIEW temp.dn_w;
+DROP TABLE temp.dn_w_src;
+DROP TABLE main.dn_w;
+
+DROP VIEW temp.dual_name;
+DROP TABLE temp.dn_src;
+DROP TABLE main.dual_name;
+
+-- Test 28: a user-declared (non-`temp`) schema behaves identically — the `temp`
+-- coverage above must not be reading a temp-only special case.
+CREATE TABLE myapp.ut (id INTEGER PRIMARY KEY, x INTEGER);
+INSERT INTO myapp.ut VALUES (1, 10);
+CREATE VIEW myapp.uv AS SELECT id, x FROM ut;
+
+SELECT * FROM uv;
+-- error: Did you mean: myapp.uv?
+
+PRAGMA schema_path = 'myapp,main';
+
+SELECT * FROM uv;
+→ [{"id":1,"x":10}]
+
+INSERT INTO uv (id, x) VALUES (2, 20);
+
+SELECT id, x FROM myapp.ut ORDER BY id;
+→ [{"id":1,"x":10},{"id":2,"x":20}]
+
+DELETE FROM uv WHERE id = 2;
+
+PRAGMA schema_path = 'main';
+
+SELECT id, x FROM uv WITH SCHEMA myapp;
+→ [{"id":1,"x":10}]
+
+DROP VIEW myapp.uv;
+DROP TABLE myapp.ut;

package/test/logic/06.4.1-schema-case-insensitive.sqllogic

@@ -0,0 +1,83 @@
+-- Schema Case-Insensitive Name Tests
+-- Verifies that schema names are case-insensitive throughout the system
+
+-- Setup: Create a custom schema with mixed-case name via declarative schema
+declare schema MyApp {
+	table items {
+		id INTEGER PRIMARY KEY,
+		name TEXT
+	}
+
+	seed items (
+		(1, 'Widget'),
+		(2, 'Gadget')
+	)
+}
+
+-- run
+
+apply schema MyApp with seed;
+
+-- run
+
+-- Test 1: Access table using original case
+SELECT * FROM MyApp.items ORDER BY id;
+→ [{"id":1,"name":"Widget"},{"id":2,"name":"Gadget"}]
+
+-- Test 2: Access table using lowercase schema name
+SELECT * FROM myapp.items ORDER BY id;
+→ [{"id":1,"name":"Widget"},{"id":2,"name":"Gadget"}]
+
+-- Test 3: Access table using uppercase schema name
+SELECT * FROM MYAPP.items ORDER BY id;
+→ [{"id":1,"name":"Widget"},{"id":2,"name":"Gadget"}]
+
+-- Test 4: Access table using mixed case schema name
+SELECT * FROM mYaPp.items ORDER BY id;
+→ [{"id":1,"name":"Widget"},{"id":2,"name":"Gadget"}]
+
+-- Test 5: INSERT using different case schema name
+INSERT INTO myapp.items VALUES (3, 'Doohickey');
+
+SELECT * FROM MyApp.items WHERE id = 3;
+→ [{"id":3,"name":"Doohickey"}]
+
+-- Test 6: UPDATE using different case schema name
+UPDATE MYAPP.items SET name = 'Updated Widget' WHERE id = 1;
+
+SELECT name FROM myapp.items WHERE id = 1;
+→ [{"name":"Updated Widget"}]
+
+-- Test 7: DELETE using different case schema name
+DELETE FROM mYaPp.items WHERE id = 3;
+
+SELECT COUNT(*) as cnt FROM MyApp.items;
+→ [{"cnt":2}]
+
+-- Test 8: Main schema is also case-insensitive
+CREATE TABLE test_main (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO test_main VALUES (1, 'hello');
+
+SELECT * FROM Main.test_main;
+→ [{"id":1,"val":"hello"}]
+
+SELECT * FROM MAIN.test_main;
+→ [{"id":1,"val":"hello"}]
+
+DROP TABLE test_main;
+
+-- Test 9: Views with mixed-case schema names
+CREATE VIEW myapp.item_names AS SELECT name FROM myapp.items;
+
+SELECT * FROM MyApp.item_names ORDER BY name;
+→ [{"name":"Gadget"},{"name":"Updated Widget"}]
+
+SELECT * FROM MYAPP.item_names ORDER BY name;
+→ [{"name":"Gadget"},{"name":"Updated Widget"}]
+
+-- Test 10: Drop view with different case
+DROP VIEW MyApp.item_names;
+
+SELECT * FROM myapp.item_names;
+-- error:
+