@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/41.9-fk-restrict-batched.sqllogic

@@ -0,0 +1,290 @@
+-- Batched parent-side RESTRICT enforcement (fk-restrict-statement-batch).
+-- A DELETE/UPDATE whose inbound FKs are all non-self-referential RESTRICT under
+-- default conflict resolution enforces them with ONE probe per FK at end of
+-- statement instead of per row. Final state + error class must be identical to
+-- per-row enforcement; these cases pin that equivalence plus the shapes the
+-- gate routes back to the per-row path.
+
+pragma foreign_keys = true;
+
+-- ===================================
+-- 1. Batchable multi-row DELETE with an existing child: error + full rollback
+-- ===================================
+
+create table bp (id integer primary key);
+create table bc (cid integer primary key, p_id integer,
+	foreign key (p_id) references bp(id) on delete restrict);
+
+insert into bp values (1), (2), (3), (4), (5);
+-- Only the LAST-scanned parent is referenced, so every earlier row deletes
+-- before the violation is detected — the statement must still undo them all.
+insert into bc values (10, 5);
+
+delete from bp;
+-- error: violates RESTRICT from 'bc'
+
+-- Atomic: all five parents survive.
+select count(*) as cnt from bp;
+→ [{"cnt":5}]
+
+-- ===================================
+-- 2. Batchable DELETE with zero referencing children succeeds
+-- ===================================
+
+delete from bc;
+delete from bp;
+select count(*) as cnt from bp;
+→ [{"cnt":0}]
+
+drop table bc;
+drop table bp;
+
+-- ===================================
+-- 3. UPDATE re-keying a referenced parent: violation at flush, atomic rollback
+-- ===================================
+
+create table up (id integer primary key, label text);
+create table uc (cid integer primary key, p_id integer,
+	foreign key (p_id) references up(id) on update restrict);
+
+insert into up values (1, 'a'), (2, 'b'), (3, 'c');
+insert into uc values (10, 2);
+
+-- Re-keys every parent; parent 2 is referenced -> whole statement rolls back.
+update up set id = id + 100;
+-- error: violates RESTRICT from 'uc'
+
+select id from up order by id;
+→ [{"id":1},{"id":2},{"id":3}]
+
+-- ===================================
+-- 4. UPDATE touching no referenced column contributes nothing to the batch
+-- ===================================
+
+update up set label = label || '!';
+select label from up order by id;
+→ [{"label":"a!"},{"label":"b!"},{"label":"c!"}]
+
+-- Re-keying only unreferenced parents succeeds (referenced key 2 unchanged).
+update up set id = id + 100 where id in (1, 3);
+select id from up order by id;
+→ [{"id":2},{"id":101},{"id":103}]
+
+drop table uc;
+drop table up;
+
+-- ===================================
+-- 5. Self-referential RESTRICT FK keeps per-row semantics (gate fallback)
+-- ===================================
+
+create table tree (id integer primary key, parent_id integer null,
+	foreign key (parent_id) references tree(id) on delete restrict);
+
+insert into tree values (1, null), (2, 1);
+
+-- Per-row: the check for row 1 sees row 2 still referencing it -> error.
+-- (A statement-end check over the post-delete state would wrongly pass.)
+delete from tree;
+-- error: constraint
+
+select count(*) as cnt from tree;
+→ [{"cnt":2}]
+
+-- Child-first order deletes cleanly row by row.
+delete from tree where id = 2;
+delete from tree where id = 1;
+select count(*) as cnt from tree;
+→ [{"cnt":0}]
+
+drop table tree;
+
+-- ===================================
+-- 6. Mixed inbound actions (restrict + cascade) fall back to per-row
+-- ===================================
+
+create table mp (id integer primary key);
+create table mc_r (cid integer primary key, p_id integer,
+	foreign key (p_id) references mp(id) on delete restrict);
+create table mc_c (cid integer primary key, p_id integer,
+	foreign key (p_id) references mp(id) on delete cascade);
+
+insert into mp values (1), (2);
+insert into mc_c values (20, 1);
+
+-- Only the cascade child references parent 1 -> delete cascades cleanly.
+delete from mp where id = 1;
+select count(*) as cnt from mc_c;
+→ [{"cnt":0}]
+
+insert into mc_r values (30, 2);
+delete from mp where id = 2;
+-- error: constraint
+
+select id from mp;
+→ [{"id":2}]
+
+drop table mc_c;
+drop table mc_r;
+drop table mp;
+
+-- ===================================
+-- 7. Composite (two-column) RESTRICT FK batches with OR-of-conjunctions probe
+-- ===================================
+
+create table kp (a integer not null, b integer not null, v text,
+	primary key (a, b));
+create table kc (cid integer primary key, ca integer, cb integer,
+	foreign key (ca, cb) references kp(a, b) on delete restrict);
+
+insert into kp values (1, 1, 'x'), (1, 2, 'y'), (2, 1, 'z');
+insert into kc values (10, 1, 2);
+
+delete from kp;
+-- error: violates RESTRICT from 'kc'
+
+select count(*) as cnt from kp;
+→ [{"cnt":3}]
+
+-- Deleting only unreferenced composite keys succeeds; (1,2) stays guarded.
+delete from kp where not (a = 1 and b = 2);
+select a, b from kp;
+→ [{"a":1,"b":2}]
+
+drop table kc;
+drop table kp;
+
+-- ===================================
+-- 8. NOCASE collation on the FK column: batched probe compares like per-row
+-- ===================================
+
+create table np (code text primary key collate nocase);
+create table nc (cid integer primary key, p_code text collate nocase,
+	foreign key (p_code) references np(code) on delete restrict);
+
+insert into np values ('ABC'), ('DEF');
+-- Case-variant reference: satisfies the child-side check under NOCASE.
+insert into nc values (10, 'abc');
+
+-- The batched IN probe rides the child column's NOCASE collation -> violation.
+delete from np where code = 'ABC';
+-- error: violates RESTRICT from 'nc'
+
+select code from np order by code;
+→ [{"code":"ABC"},{"code":"DEF"}]
+
+delete from np where code = 'def';
+select code from np;
+→ [{"code":"ABC"}]
+
+drop table nc;
+drop table np;
+
+-- ===================================
+-- 9. NULL referenced values are excluded (MATCH SIMPLE) — nothing to probe
+-- ===================================
+
+create table xp (id integer primary key, alt integer null unique);
+create table xc (cid integer primary key, p_alt integer null,
+	foreign key (p_alt) references xp(alt) on delete restrict);
+
+insert into xp (id, alt) values (1, null), (2, null), (3, 30);
+insert into xc values (10, 30);
+
+-- NULL alt values participate in no FK match: deletes succeed.
+delete from xp where alt is null;
+select id from xp;
+→ [{"id":3}]
+
+delete from xp where id = 3;
+-- error: violates RESTRICT from 'xc'
+
+drop table xc;
+drop table xp;
+
+-- ===================================
+-- 10. Multiple inbound RESTRICT FKs: each gets its own batch + probe
+-- ===================================
+
+create table zp (id integer primary key);
+create table zc1 (cid integer primary key, p_id integer,
+	foreign key (p_id) references zp(id) on delete restrict);
+create table zc2 (cid integer primary key, p_id integer,
+	foreign key (p_id) references zp(id) on delete restrict);
+
+insert into zp values (1), (2);
+-- Only the SECOND-declared child holds a reference.
+insert into zc2 values (20, 2);
+
+delete from zp where id = 1;
+select id from zp;
+→ [{"id":2}]
+
+delete from zp where id = 2;
+-- error: violates RESTRICT from 'zc2'
+
+drop table zc2;
+drop table zc1;
+drop table zp;
+
+-- ===================================
+-- 11. Referenced-column-change short-circuit coerces before comparing
+-- (regression for bug-fk-restrict-change-detection-uncoerced): a rewrite that
+-- spells the same stored value differently must not contribute a key to the
+-- batch, so accumulateParentRestrictKeys must not flush a spurious probe.
+-- ===================================
+
+create table crb_p (id integer primary key);
+create table crb_c (cid integer primary key, p_id integer,
+	foreign key (p_id) references crb_p(id) on update restrict);
+
+insert into crb_p values (1), (2);
+insert into crb_c values (10, 1);
+
+-- Integer key rewritten as text '1': same stored value, no batch entry.
+update crb_p set id = '1' where id = 1;
+select id from crb_p order by id;
+→ [{"id":1},{"id":2}]
+
+-- Genuine re-key of the referenced row still flushes a violating probe.
+update crb_p set id = 100 where id = 1;
+-- error: violates RESTRICT from 'crb_c'
+
+drop table crb_c;
+drop table crb_p;
+
+create table crbj_p (id json primary key, tag integer);
+create table crbj_c (cid integer primary key, p_id json,
+	foreign key (p_id) references crbj_p(id) on update restrict);
+
+insert into crbj_p values ('{"a":1,"b":2}', 1);
+insert into crbj_c values (10, '{"a":1,"b":2}');
+
+-- Reorder-equal JSON key: same stored value, no batch entry.
+update crbj_p set id = '{"b": 2, "a": 1}' where tag = 1;
+select id from crbj_p;
+→ [{"id":{"b":2,"a":1}}]
+
+-- Genuine JSON re-key still flushes a violating probe.
+update crbj_p set id = '{"a":9,"b":9}' where tag = 1;
+-- error: violates RESTRICT from 'crbj_c'
+
+drop table crbj_c;
+drop table crbj_p;
+
+-- The re-coercion compares BINARY on purpose: the column's collation says which
+-- values an equality test calls equal, not which value gets STORED. A case-only
+-- rewrite of a `collate nocase` key does change the stored value, so it must still
+-- count as a change and flush a violating probe.
+
+create table crbn_p (id text collate nocase primary key);
+create table crbn_c (cid integer primary key, p_id text,
+	foreign key (p_id) references crbn_p(id) on update restrict);
+
+insert into crbn_p values ('A');
+insert into crbn_c values (10, 'A');
+
+update crbn_p set id = 'a' where id = 'A';
+-- error: violates RESTRICT from 'crbn_c'
+
+drop table crbn_c;
+drop table crbn_p;

package/test/logic/42-committed-snapshot.sqllogic

@@ -0,0 +1,254 @@
+-- committed-snapshot.sqllogic - Testing committed.tablename pseudo-schema access
+
+-- ===================================
+-- Basic: committed.* returns pre-transaction data
+-- ===================================
+
+CREATE TABLE accounts (id INTEGER PRIMARY KEY, balance INTEGER);
+INSERT INTO accounts VALUES (1, 100);
+INSERT INTO accounts VALUES (2, 200);
+COMMIT;
+
+-- Within a transaction, committed.accounts should show original data
+BEGIN;
+UPDATE accounts SET balance = 50 WHERE id = 1;
+SELECT balance FROM accounts WHERE id = 1;
+→ [{ "balance": 50 }]
+SELECT balance FROM committed.accounts WHERE id = 1;
+→ [{ "balance": 100 }]
+COMMIT;
+
+-- After commit, committed.accounts shows the new committed state
+SELECT balance FROM committed.accounts WHERE id = 1;
+→ [{ "balance": 50 }]
+
+DROP TABLE accounts;
+-- run
+
+-- ===================================
+-- committed.* outside a transaction returns current data
+-- ===================================
+
+CREATE TABLE t1 (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO t1 VALUES (1, 'hello');
+COMMIT;
+
+-- Outside a transaction (autocommit), committed should match current
+SELECT val FROM committed.t1 WHERE id = 1;
+→ [{ "val": "hello" }]
+
+DROP TABLE t1;
+-- run
+
+-- ===================================
+-- committed.* is read-only (INSERT error)
+-- ===================================
+
+CREATE TABLE ro_test (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO ro_test VALUES (1, 'x');
+-- run
+
+INSERT INTO committed.ro_test VALUES (2, 'y');
+-- error: Cannot modify committed-state table 'committed.ro_test'
+
+DROP TABLE ro_test;
+-- run
+
+-- ===================================
+-- committed.* is read-only (UPDATE error)
+-- ===================================
+
+CREATE TABLE ro_test2 (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO ro_test2 VALUES (1, 'x');
+-- run
+
+UPDATE committed.ro_test2 SET val = 'z' WHERE id = 1;
+-- error: Cannot modify committed-state table 'committed.ro_test2'
+
+DROP TABLE ro_test2;
+-- run
+
+-- ===================================
+-- committed.* is read-only (DELETE error)
+-- ===================================
+
+CREATE TABLE ro_test3 (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO ro_test3 VALUES (1, 'x');
+-- run
+
+DELETE FROM committed.ro_test3 WHERE id = 1;
+-- error: Cannot modify committed-state table 'committed.ro_test3'
+
+DROP TABLE ro_test3;
+-- run
+
+-- ===================================
+-- JOIN between current and committed state
+-- ===================================
+
+CREATE TABLE products (id INTEGER PRIMARY KEY, price INTEGER);
+INSERT INTO products VALUES (1, 10);
+INSERT INTO products VALUES (2, 20);
+COMMIT;
+
+BEGIN;
+UPDATE products SET price = 15 WHERE id = 1;
+UPDATE products SET price = 25 WHERE id = 2;
+
+-- Join current with committed to see price changes
+SELECT p.id, p.price AS new_price, cp.price AS old_price
+FROM products p
+JOIN committed.products cp ON p.id = cp.id
+ORDER BY p.id;
+→ [{ "id": 1, "new_price": 15, "old_price": 10 }, { "id": 2, "new_price": 25, "old_price": 20 }]
+COMMIT;
+
+DROP TABLE products;
+-- run
+
+-- ===================================
+-- committed.* with multiple tables
+-- ===================================
+
+CREATE TABLE t_a (id INTEGER PRIMARY KEY, val INTEGER);
+CREATE TABLE t_b (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO t_a VALUES (1, 100);
+INSERT INTO t_b VALUES (1, 200);
+COMMIT;
+
+BEGIN;
+UPDATE t_a SET val = 111 WHERE id = 1;
+UPDATE t_b SET val = 222 WHERE id = 1;
+
+SELECT a.val AS a_new, ca.val AS a_old, b.val AS b_new, cb.val AS b_old
+FROM t_a a
+JOIN committed.t_a ca ON a.id = ca.id
+JOIN t_b b ON a.id = b.id
+JOIN committed.t_b cb ON b.id = cb.id
+WHERE a.id = 1;
+→ [{ "a_new": 111, "a_old": 100, "b_new": 222, "b_old": 200 }]
+COMMIT;
+
+DROP TABLE t_b;
+DROP TABLE t_a;
+-- run
+
+-- ===================================
+-- Savepoint: committed state doesn't change after savepoints
+-- ===================================
+
+CREATE TABLE sp_test (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO sp_test VALUES (1, 10);
+COMMIT;
+
+BEGIN;
+UPDATE sp_test SET val = 20 WHERE id = 1;
+SAVEPOINT sp1;
+UPDATE sp_test SET val = 30 WHERE id = 1;
+
+-- committed.sp_test should still show the pre-transaction value
+SELECT val FROM committed.sp_test WHERE id = 1;
+→ [{ "val": 10 }]
+
+-- Current state shows latest update
+SELECT val FROM sp_test WHERE id = 1;
+→ [{ "val": 30 }]
+
+ROLLBACK TO SAVEPOINT sp1;
+
+-- committed.sp_test still shows original
+SELECT val FROM committed.sp_test WHERE id = 1;
+→ [{ "val": 10 }]
+
+-- Current state shows value before savepoint
+SELECT val FROM sp_test WHERE id = 1;
+→ [{ "val": 20 }]
+
+COMMIT;
+
+DROP TABLE sp_test;
+-- run
+
+-- ===================================
+-- Assertion with committed reference: detect balance decrease
+-- ===================================
+
+CREATE TABLE accts (id INTEGER PRIMARY KEY, balance INTEGER);
+INSERT INTO accts VALUES (1, 100);
+INSERT INTO accts VALUES (2, 200);
+COMMIT;
+
+-- Assertion: no account's balance may decrease
+CREATE ASSERTION no_balance_decrease CHECK (NOT EXISTS (
+  SELECT 1 FROM accts a
+  JOIN committed.accts ca ON a.id = ca.id
+  WHERE a.balance < ca.balance
+));
+-- run
+
+-- Valid: increase balance
+BEGIN;
+UPDATE accts SET balance = 150 WHERE id = 1;
+COMMIT;
+-- run
+
+SELECT balance FROM accts WHERE id = 1;
+→ [{ "balance": 150 }]
+
+-- Invalid: decrease balance
+BEGIN;
+UPDATE accts SET balance = 50 WHERE id = 1;
+COMMIT;
+-- error: Integrity assertion failed: no_balance_decrease
+
+-- State should be unchanged
+SELECT balance FROM accts WHERE id = 1;
+→ [{ "balance": 150 }]
+
+DROP ASSERTION no_balance_decrease;
+DROP TABLE accts;
+-- run
+
+-- ===================================
+-- Assertion with committed reference: passes when constraint holds
+-- ===================================
+
+CREATE TABLE vals (id INTEGER PRIMARY KEY, v INTEGER);
+INSERT INTO vals VALUES (1, 10);
+COMMIT;
+
+-- Assertion: values can only increase or stay the same
+CREATE ASSERTION monotonic CHECK (NOT EXISTS (
+  SELECT 1 FROM vals curr
+  JOIN committed.vals prev ON curr.id = prev.id
+  WHERE curr.v < prev.v
+));
+-- run
+
+-- Equal value: OK
+BEGIN;
+UPDATE vals SET v = 10 WHERE id = 1;
+COMMIT;
+-- run
+
+-- Increase: OK
+BEGIN;
+UPDATE vals SET v = 20 WHERE id = 1;
+COMMIT;
+-- run
+
+SELECT v FROM vals WHERE id = 1;
+→ [{ "v": 20 }]
+
+-- New row (no committed counterpart): OK
+BEGIN;
+INSERT INTO vals VALUES (2, 5);
+COMMIT;
+-- run
+
+SELECT v FROM vals WHERE id = 2;
+→ [{ "v": 5 }]
+
+DROP ASSERTION monotonic;
+DROP TABLE vals;
+-- run

package/test/logic/42-returning.sqllogic

@@ -0,0 +1,159 @@
+-- 42-returning.sqllogic - Testing RETURNING clauses
+
+-- === Basic RETURNING tests ===
+
+DROP TABLE IF EXISTS test_returning;
+CREATE TABLE test_returning (
+    id INTEGER PRIMARY KEY,
+    name TEXT,
+    value INTEGER DEFAULT 100
+);
+
+-- INSERT with RETURNING
+INSERT INTO test_returning (id, name) VALUES (101, 'first') RETURNING id, name, value;
+→ [{"id":101,"name":"first","value":100}]
+
+INSERT INTO test_returning (id, name, value) VALUES (102, 'second', 200) RETURNING *;
+→ [{"id":102,"name":"second","value":200}]
+
+INSERT INTO test_returning (id, name, value) VALUES (103, 'third', 300) RETURNING id, name;
+→ [{"id":103,"name":"third"}]
+
+-- Verify data was actually inserted (102 was inserted via RETURNING * above)
+SELECT * FROM test_returning ORDER BY id;
+→ [{"id":101,"name":"first","value":100},{"id":102,"name":"second","value":200},{"id":103,"name":"third","value":300}]
+
+-- UPDATE with RETURNING
+UPDATE test_returning SET value = value + 50 WHERE id = 101 RETURNING id, name, value;
+→ [{"id":101,"name":"first","value":150}]
+
+-- UPDATE multiple rows with RETURNING
+UPDATE test_returning SET name = name || '_updated' RETURNING id, name;
+→ [{"id":101,"name":"first_updated"},{"id":102,"name":"second_updated"},{"id":103,"name":"third_updated"}]
+
+-- Verify updates were applied
+SELECT * FROM test_returning ORDER BY id;
+→ [{"id":101,"name":"first_updated","value":150},{"id":102,"name":"second_updated","value":200},{"id":103,"name":"third_updated","value":300}]
+
+-- DELETE with RETURNING
+DELETE FROM test_returning WHERE id = 103 RETURNING id, name, value;
+→ [{"id":103,"name":"third_updated","value":300}]
+
+-- Verify deletion (102 remains; only 103 was deleted)
+SELECT * FROM test_returning ORDER BY id;
+→ [{"id":101,"name":"first_updated","value":150},{"id":102,"name":"second_updated","value":200}]
+
+-- === RETURNING with expressions ===
+
+INSERT INTO test_returning (id, name, value) VALUES (104, 'fourth', 400) RETURNING id, upper(name), value * 2;
+→ [{"id":104,"upper(name)":"FOURTH","value * 2":800}]
+
+INSERT INTO test_returning (id, name, value) VALUES (105, 'fifth', 500) RETURNING id, name AS item_name, value + 100 AS adjusted_value;
+→ [{"id":105,"item_name":"fifth","adjusted_value":600}]
+
+-- === RETURNING with constraints (should only return if operation succeeds) ===
+
+DROP TABLE test_returning;
+
+CREATE TABLE test_constrained (
+    id INTEGER PRIMARY KEY,
+    positive_value INTEGER CHECK(positive_value > 0),
+    name TEXT NOT NULL
+);
+
+-- Successful INSERT with RETURNING
+INSERT INTO test_constrained (id, positive_value, name) VALUES (201, 10, 'valid') RETURNING id, positive_value;
+→ [{"id":201,"positive_value":10}]
+
+-- Failed INSERT due to constraint - should not return anything
+INSERT INTO test_constrained (id, positive_value, name) VALUES (202, -5, 'invalid') RETURNING id, positive_value;
+-- error: CHECK constraint failed: _check_positive_value
+
+-- Failed INSERT due to NOT NULL - should not return anything
+INSERT INTO test_constrained (id, positive_value, name) VALUES (203, 15, NULL) RETURNING id, name;
+-- error: NOT NULL constraint failed: test_constrained.name
+
+-- Verify only the successful insert was applied
+SELECT * FROM test_constrained;
+→ [{"id":201,"positive_value":10,"name":"valid"}]
+
+-- Successful UPDATE with RETURNING
+UPDATE test_constrained SET positive_value = 20 WHERE id = 201 RETURNING id, positive_value;
+→ [{"id":201,"positive_value":20}]
+
+-- Failed UPDATE due to constraint - should not return anything
+UPDATE test_constrained SET positive_value = -1 WHERE id = 201 RETURNING id, positive_value;
+-- error: CHECK constraint failed: _check_positive_value
+
+-- Verify failed update didn't change anything
+SELECT positive_value FROM test_constrained WHERE id = 201;
+→ [{"positive_value":20}]
+
+-- === RETURNING with no matching rows ===
+
+-- UPDATE with WHERE that matches nothing
+UPDATE test_constrained SET positive_value = 30 WHERE id = 999 RETURNING id, positive_value;
+→ []
+
+-- DELETE with WHERE that matches nothing
+DELETE FROM test_constrained WHERE name = 'nonexistent' RETURNING id, name;
+→ []
+
+-- === Multiple row RETURNING ===
+
+INSERT INTO test_constrained (id, positive_value, name) VALUES
+    (210, 100, 'row1'),
+    (211, 110, 'row2'),
+    (212, 120, 'row3')
+RETURNING id, name;
+→ [{"id":210,"name":"row1"},{"id":211,"name":"row2"},{"id":212,"name":"row3"}]
+
+-- Update multiple rows
+UPDATE test_constrained SET positive_value = positive_value + 5 WHERE id >= 210 RETURNING id, positive_value;
+→ [{"id":210,"positive_value":105},{"id":211,"positive_value":115},{"id":212,"positive_value":125}]
+
+-- Delete multiple rows
+DELETE FROM test_constrained WHERE id >= 210 RETURNING name;
+→ [{"name":"row1"},{"name":"row2"},{"name":"row3"}]
+
+DROP TABLE test_constrained;
+
+-- === OLD/NEW qualifiers in RETURNING ===
+
+-- Create test table
+CREATE TABLE test_table (
+    id INTEGER PRIMARY KEY,
+    value TEXT
+);
+
+-- Insert initial data
+INSERT INTO test_table VALUES (1, 'original');
+SELECT * FROM test_table;
+→ [{"id":1,"value":"original"}]
+
+-- Test UPDATE RETURNING with OLD qualifier (should show original value)
+UPDATE test_table SET value = 'updated' WHERE id = 1 RETURNING OLD.value;
+→ [{"OLD.value":"original"}]
+
+-- Verify the update actually happened
+SELECT * FROM test_table;
+→ [{"id":1,"value":"updated"}]
+
+-- RETURNING preserves the user's spelling for output column names
+INSERT INTO test_table VALUES (2, 'second');
+UPDATE test_table SET value = 'modified' WHERE id = 2 RETURNING NEW.value, OLD.value;
+→ [{"NEW.value":"modified","OLD.value":"second"}]
+
+-- Aliases are emitted with the case as written
+UPDATE test_table SET value = 'final' WHERE id = 2 RETURNING NEW.value AS NewValue, OLD.value AS OldValue;
+→ [{"NewValue":"final","OldValue":"modified"}]
+
+-- INSERT with NEW qualifier — qualifier case preserved
+INSERT INTO test_table VALUES (3, 'third') RETURNING NEW.id, NEW.value;
+→ [{"NEW.id":3,"NEW.value":"third"}]
+
+-- DELETE with OLD qualifier — qualifier case preserved
+DELETE FROM test_table WHERE id = 3 RETURNING OLD.id, OLD.value;
+→ [{"OLD.id":3,"OLD.value":"third"}]
+
+DROP TABLE test_table;