@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/101-transaction-edge-cases.sqllogic

@@ -0,0 +1,395 @@
+-- transaction-edge-cases.sqllogic - Edge cases for savepoint nesting, empty txns, commit-after-fail
+
+-- ===================================
+-- Empty Transactions
+-- ===================================
+
+CREATE TABLE txe (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO txe VALUES (1, 'initial');
+
+-- BEGIN + COMMIT with no mutations
+BEGIN;
+COMMIT;
+
+SELECT val FROM txe WHERE id = 1;
+→ [{"val": "initial"}]
+
+-- BEGIN + ROLLBACK with no mutations
+BEGIN;
+ROLLBACK;
+
+SELECT val FROM txe WHERE id = 1;
+→ [{"val": "initial"}]
+
+-- ===================================
+-- Double BEGIN (should error)
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (2, 'in-txn');
+COMMIT;
+-- run
+
+-- Second BEGIN while already in transaction
+BEGIN;
+BEGIN;
+-- error: a transaction is already active
+
+ROLLBACK;
+-- run
+
+SELECT val FROM txe WHERE id = 2;
+→ [{"val": "in-txn"}]
+
+-- ===================================
+-- Double COMMIT (second is no-op)
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (3, 'commit-twice');
+COMMIT;
+COMMIT;
+-- run
+
+SELECT val FROM txe WHERE id = 3;
+→ [{"val": "commit-twice"}]
+
+-- ===================================
+-- Double ROLLBACK (second is no-op)
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (99, 'will-rollback');
+ROLLBACK;
+ROLLBACK;
+-- run
+
+SELECT count(*) as cnt FROM txe WHERE id = 99;
+→ [{"cnt": 0}]
+
+-- ===================================
+-- Commit After Failed Statement
+-- ===================================
+-- A failed statement mid-transaction should not prevent subsequent operations
+
+BEGIN;
+INSERT INTO txe VALUES (4, 'before-fail');
+-- run
+
+-- This should fail (duplicate key)
+INSERT INTO txe VALUES (1, 'duplicate');
+-- error: UNIQUE constraint failed
+
+-- Transaction should still be usable after the failed statement
+INSERT INTO txe VALUES (5, 'after-fail');
+COMMIT;
+-- run
+
+SELECT val FROM txe WHERE id = 4;
+→ [{"val": "before-fail"}]
+
+SELECT val FROM txe WHERE id = 5;
+→ [{"val": "after-fail"}]
+
+-- ===================================
+-- Deeply Nested Savepoints (3+ levels)
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (10, 'base');
+SAVEPOINT sp_a;
+INSERT INTO txe VALUES (11, 'level-1');
+SAVEPOINT sp_b;
+INSERT INTO txe VALUES (12, 'level-2');
+SAVEPOINT sp_c;
+INSERT INTO txe VALUES (13, 'level-3');
+
+-- Verify all visible within transaction
+SELECT count(*) as cnt FROM txe WHERE id >= 10;
+→ [{"cnt": 4}]
+
+-- Rollback innermost only
+ROLLBACK TO SAVEPOINT sp_c;
+SELECT count(*) as cnt FROM txe WHERE id >= 10;
+→ [{"cnt": 3}]
+
+-- sp_c is preserved after rollback — can reuse
+INSERT INTO txe VALUES (14, 'reuse-sp_c');
+RELEASE SAVEPOINT sp_c;
+
+-- Rollback to sp_b discards sp_c's released data plus sp_b's data
+ROLLBACK TO SAVEPOINT sp_b;
+SELECT count(*) as cnt FROM txe WHERE id >= 10;
+→ [{"cnt": 2}]
+
+-- Release sp_b and sp_a, then commit
+RELEASE SAVEPOINT sp_b;
+RELEASE SAVEPOINT sp_a;
+COMMIT;
+
+-- Only base + level-1 should survive
+SELECT val FROM txe WHERE id IN (10, 11) ORDER BY id;
+→ [{"val": "base"}, {"val": "level-1"}]
+
+SELECT count(*) as cnt FROM txe WHERE id >= 12;
+→ [{"cnt": 0}]
+
+-- ===================================
+-- Release inner savepoint then rollback outer
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (20, 'outer');
+SAVEPOINT sp_outer;
+INSERT INTO txe VALUES (21, 'inner-pre');
+SAVEPOINT sp_inner;
+INSERT INTO txe VALUES (22, 'inner-post');
+RELEASE SAVEPOINT sp_inner;
+
+-- inner-post is now merged into sp_outer scope
+SELECT count(*) as cnt FROM txe WHERE id >= 20;
+→ [{"cnt": 3}]
+
+-- Rollback sp_outer undoes everything including released inner data
+ROLLBACK TO SAVEPOINT sp_outer;
+SELECT count(*) as cnt FROM txe WHERE id >= 20;
+→ [{"cnt": 1}]
+
+RELEASE SAVEPOINT sp_outer;
+COMMIT;
+
+SELECT val FROM txe WHERE id = 20;
+→ [{"val": "outer"}]
+
+SELECT count(*) as cnt FROM txe WHERE id IN (21, 22);
+→ [{"cnt": 0}]
+
+-- ===================================
+-- Savepoint with same name at different nesting levels
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (30, 'base');
+SAVEPOINT dup;
+INSERT INTO txe VALUES (31, 'dup-level-1');
+SAVEPOINT dup;
+INSERT INTO txe VALUES (32, 'dup-level-2');
+
+-- ROLLBACK TO dup goes to the most recent (innermost) 'dup'
+ROLLBACK TO SAVEPOINT dup;
+SELECT count(*) as cnt FROM txe WHERE id = 32;
+→ [{"cnt": 0}]
+
+-- level-1 data should still be visible
+SELECT count(*) as cnt FROM txe WHERE id = 31;
+→ [{"cnt": 1}]
+
+RELEASE SAVEPOINT dup;
+RELEASE SAVEPOINT dup;
+COMMIT;
+
+SELECT val FROM txe WHERE id IN (30, 31) ORDER BY id;
+→ [{"val": "base"}, {"val": "dup-level-1"}]
+
+-- ===================================
+-- Mutation types across savepoints
+-- ===================================
+-- INSERT, UPDATE, DELETE across savepoint boundaries
+
+BEGIN;
+INSERT INTO txe VALUES (40, 'inserted');
+SAVEPOINT sp_mut;
+UPDATE txe SET val = 'updated' WHERE id = 40;
+SAVEPOINT sp_del;
+DELETE FROM txe WHERE id = 40;
+
+-- Row is gone within innermost scope
+SELECT count(*) as cnt FROM txe WHERE id = 40;
+→ [{"cnt": 0}]
+
+-- Rollback the delete
+ROLLBACK TO SAVEPOINT sp_del;
+SELECT val FROM txe WHERE id = 40;
+→ [{"val": "updated"}]
+
+-- Rollback the update too
+ROLLBACK TO SAVEPOINT sp_mut;
+SELECT val FROM txe WHERE id = 40;
+→ [{"val": "inserted"}]
+
+RELEASE SAVEPOINT sp_mut;
+COMMIT;
+
+SELECT val FROM txe WHERE id = 40;
+→ [{"val": "inserted"}]
+
+-- ===================================
+-- Large transaction with many inserts
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (100, 'r100');
+INSERT INTO txe VALUES (101, 'r101');
+INSERT INTO txe VALUES (102, 'r102');
+INSERT INTO txe VALUES (103, 'r103');
+INSERT INTO txe VALUES (104, 'r104');
+INSERT INTO txe VALUES (105, 'r105');
+INSERT INTO txe VALUES (106, 'r106');
+INSERT INTO txe VALUES (107, 'r107');
+INSERT INTO txe VALUES (108, 'r108');
+INSERT INTO txe VALUES (109, 'r109');
+COMMIT;
+
+SELECT count(*) as cnt FROM txe WHERE id >= 100;
+→ [{"cnt": 10}]
+
+-- ===================================
+-- Rollback large transaction
+-- ===================================
+
+BEGIN;
+INSERT INTO txe VALUES (200, 'will-rollback');
+INSERT INTO txe VALUES (201, 'will-rollback');
+INSERT INTO txe VALUES (202, 'will-rollback');
+INSERT INTO txe VALUES (203, 'will-rollback');
+INSERT INTO txe VALUES (204, 'will-rollback');
+ROLLBACK;
+
+SELECT count(*) as cnt FROM txe WHERE id >= 200;
+→ [{"cnt": 0}]
+
+-- ===================================
+-- Implicit transaction auto-commits on success
+-- ===================================
+
+INSERT INTO txe VALUES (300, 'auto');
+
+SELECT val FROM txe WHERE id = 300;
+→ [{"val": "auto"}]
+
+-- ===================================
+-- Savepoint without explicit BEGIN (creates implicit transaction)
+-- ===================================
+
+SAVEPOINT implicit_sp;
+INSERT INTO txe VALUES (301, 'in-implicit-sp');
+RELEASE SAVEPOINT implicit_sp;
+
+SELECT val FROM txe WHERE id = 301;
+→ [{"val": "in-implicit-sp"}]
+
+-- ===================================
+-- Statement-level atomicity inside an explicit transaction (UPDATE)
+-- ===================================
+-- A multi-row UPDATE whose Nth row throws must roll back the WHOLE statement
+-- (rows 1..N-1 included), mirroring SQLite's implicit-savepoint-per-statement.
+-- The autocommit path is already atomic via implicit-transaction rollback, so
+-- this MUST wrap in begin/rollback to exercise the statement savepoint. Without
+-- it, id=1's update (x=11) would survive the aborted statement.
+
+-- The preceding section upgraded an implicit savepoint to an explicit
+-- transaction that is still open; commit it so our BEGIN starts clean
+-- (a no-op if autocommit is already active).
+COMMIT;
+-- run
+
+CREATE TABLE atom_u (id INTEGER PRIMARY KEY, x INTEGER NOT NULL);
+INSERT INTO atom_u VALUES (1, 10), (2, 20), (3, 30);
+-- run
+
+-- Row id=1 updates to x=11 first, then id=2 violates NOT NULL (x -> NULL).
+BEGIN;
+UPDATE atom_u SET x = CASE WHEN id = 2 THEN NULL ELSE x + 1 END WHERE id IN (1, 2);
+-- error: NOT NULL constraint failed: atom_u.x
+
+-- Inside the still-open transaction: id=1's update must NOT have survived.
+SELECT id, x FROM atom_u ORDER BY id;
+→ [{"id":1,"x":10},{"id":2,"x":20},{"id":3,"x":30}]
+ROLLBACK;
+-- run
+
+-- After rollback nothing persisted either.
+SELECT id, x FROM atom_u ORDER BY id;
+→ [{"id":1,"x":10},{"id":2,"x":20},{"id":3,"x":30}]
+
+-- Same guarantee when the later row trips a UNIQUE collision rather than a
+-- NOT NULL check: id=1's k moves to 15 (fine), then id=2's k -> 30 collides
+-- with id=3. The whole statement must revert id=1's move.
+CREATE TABLE atom_uq (id INTEGER PRIMARY KEY, k INTEGER UNIQUE);
+INSERT INTO atom_uq VALUES (1, 10), (2, 20), (3, 30);
+-- run
+
+BEGIN;
+UPDATE atom_uq SET k = CASE WHEN id = 1 THEN 15 WHEN id = 2 THEN 30 END WHERE id IN (1, 2);
+-- error: constraint failed
+
+SELECT id, k FROM atom_uq ORDER BY id;
+→ [{"id":1,"k":10},{"id":2,"k":20},{"id":3,"k":30}]
+ROLLBACK;
+-- run
+
+-- ===================================
+-- Statement-level atomicity inside an explicit transaction (DELETE)
+-- ===================================
+-- A multi-row DELETE whose Nth row throws (FK RESTRICT child reference) must
+-- roll back the whole statement. id=1 (unreferenced) deletes first, then id=2
+-- (referenced by a RESTRICT child) trips the parent-side FK check.
+
+CREATE TABLE atom_dp (id INTEGER PRIMARY KEY);
+CREATE TABLE atom_dc (id INTEGER PRIMARY KEY, pid INTEGER REFERENCES atom_dp(id) ON DELETE RESTRICT);
+INSERT INTO atom_dp VALUES (1), (2), (3);
+INSERT INTO atom_dc VALUES (100, 2);
+-- run
+
+BEGIN;
+DELETE FROM atom_dp WHERE id IN (1, 2);
+-- error: constraint failed
+
+-- id=1's delete must NOT have survived the aborted statement.
+SELECT id FROM atom_dp ORDER BY id;
+→ [{"id":1},{"id":2},{"id":3}]
+ROLLBACK;
+-- run
+
+SELECT id FROM atom_dp ORDER BY id;
+→ [{"id":1},{"id":2},{"id":3}]
+
+-- ===================================
+-- Rolled-back statements must not corrupt UNIQUE enforcement state
+-- ===================================
+-- Regression (memory module): secondary-index entries are shared across
+-- inherited layer trees, so a rolled-back transaction's index mutations must
+-- be copy-on-written into the transaction's own tree, never applied in place
+-- to the shared committed entry (MemoryIndex.ownedEntries). A leaked delete
+-- silently un-enforced UNIQUE; a leaked insert left a phantom candidate.
+
+CREATE TABLE rbk (id INTEGER PRIMARY KEY, v TEXT UNIQUE);
+INSERT INTO rbk VALUES (1, 'x');
+
+-- a rolled-back DELETE must leave UNIQUE enforcement intact
+BEGIN;
+DELETE FROM rbk WHERE id = 1;
+ROLLBACK;
+
+INSERT INTO rbk VALUES (2, 'x');
+-- error: UNIQUE constraint failed
+
+-- a rolled-back INSERT must not leave a phantom that blocks the value
+BEGIN;
+INSERT INTO rbk VALUES (3, 'y');
+ROLLBACK;
+
+INSERT INTO rbk VALUES (4, 'y');
+SELECT id, v FROM rbk ORDER BY id;
+→ [{"id":1,"v":"x"},{"id":4,"v":"y"}]
+
+-- ===================================
+-- Cleanup
+-- ===================================
+
+DROP TABLE rbk;
+DROP TABLE txe;
+DROP TABLE atom_dc;
+DROP TABLE atom_dp;
+DROP TABLE atom_uq;
+DROP TABLE atom_u;

package/test/logic/102-schema-catalog-edge-cases.sqllogic

@@ -0,0 +1,252 @@
+-- schema-catalog-edge-cases.sqllogic - Multi-schema, DDL roundtrip, schema change events
+
+-- ===================================
+-- DDL Round-trip: Create → Export → Drop → Recreate → Verify
+-- ===================================
+
+-- Simple table DDL roundtrip: create, drop, recreate, verify identical behavior
+CREATE TABLE rt_simple (id INTEGER PRIMARY KEY, name TEXT NOT NULL, active INTEGER);
+INSERT INTO rt_simple VALUES (1, 'Alice', 1);
+
+-- Verify table_info returns expected columns
+SELECT name, type, pk FROM table_info('rt_simple') ORDER BY cid;
+→ [{"name": "id", "type": "INTEGER", "pk": 1}, {"name": "name", "type": "TEXT", "pk": 0}, {"name": "active", "type": "INTEGER", "pk": 0}]
+
+SELECT * FROM rt_simple;
+→ [{"id": 1, "name": "Alice", "active": 1}]
+
+DROP TABLE rt_simple;
+
+-- Recreate the same table and verify it works identically
+CREATE TABLE rt_simple (id INTEGER PRIMARY KEY, name TEXT NOT NULL, active INTEGER);
+INSERT INTO rt_simple VALUES (1, 'Alice', 1);
+
+SELECT * FROM rt_simple;
+→ [{"id": 1, "name": "Alice", "active": 1}]
+
+DROP TABLE rt_simple;
+
+-- ===================================
+-- Composite primary key DDL
+-- ===================================
+
+CREATE TABLE rt_composite (a INTEGER, b TEXT, c REAL, PRIMARY KEY (a, b));
+INSERT INTO rt_composite VALUES (1, 'x', 3.14), (1, 'y', 2.71), (2, 'x', 1.0);
+
+SELECT * FROM rt_composite ORDER BY a, b;
+→ [{"a": 1, "b": "x", "c": 3.14}, {"a": 1, "b": "y", "c": 2.71}, {"a": 2, "b": "x", "c": 1.0}]
+
+DROP TABLE rt_composite;
+
+-- Recreate and verify
+CREATE TABLE rt_composite (a INTEGER, b TEXT, c REAL, PRIMARY KEY (a, b));
+INSERT INTO rt_composite VALUES (1, 'x', 3.14);
+
+SELECT * FROM rt_composite;
+→ [{"a": 1, "b": "x", "c": 3.14}]
+
+DROP TABLE rt_composite;
+
+-- ===================================
+-- Table with indexes
+-- ===================================
+-- Lives in 102.0.1-schema-catalog-indexed-table (it needs standalone CREATE INDEX).
+
+-- ===================================
+-- Table with CHECK constraints
+-- ===================================
+
+CREATE TABLE rt_checked (id INTEGER PRIMARY KEY, val INTEGER CHECK (val > 0), name TEXT CHECK (length(name) > 0));
+INSERT INTO rt_checked VALUES (1, 10, 'valid');
+
+SELECT * FROM rt_checked;
+→ [{"id": 1, "val": 10, "name": "valid"}]
+
+-- Verify constraints work
+INSERT INTO rt_checked VALUES (2, -1, 'test');
+-- error: CHECK constraint failed
+
+INSERT INTO rt_checked VALUES (3, 5, '');
+-- error: CHECK constraint failed
+
+DROP TABLE rt_checked;
+
+-- ===================================
+-- Multi-schema: declare and apply
+-- ===================================
+
+declare schema app1 {
+	table customers {
+		id INTEGER PRIMARY KEY,
+		name TEXT NOT NULL
+	}
+}
+
+apply schema app1;
+-- run
+
+INSERT INTO app1.customers VALUES (1, 'Acme'), (2, 'Beta');
+
+SELECT * FROM app1.customers ORDER BY id;
+→ [{"id": 1, "name": "Acme"}, {"id": 2, "name": "Beta"}]
+
+-- ===================================
+-- Cross-schema queries
+-- ===================================
+
+CREATE TABLE main_data (id INTEGER PRIMARY KEY, val TEXT);
+INSERT INTO main_data VALUES (1, 'main-val');
+
+SELECT c.name, m.val FROM app1.customers AS c JOIN main_data AS m ON c.id = m.id;
+→ [{"name": "Acme", "val": "main-val"}]
+
+-- ===================================
+-- Schema search path resolution
+-- ===================================
+
+-- Set search path to include app1
+PRAGMA schema_path = 'app1,main';
+
+-- Unqualified 'customers' should resolve to app1.customers
+SELECT * FROM customers ORDER BY id;
+→ [{"id": 1, "name": "Acme"}, {"id": 2, "name": "Beta"}]
+
+-- Unqualified 'main_data' should resolve to main.main_data
+SELECT * FROM main_data;
+→ [{"id": 1, "val": "main-val"}]
+
+-- Reset search path
+PRAGMA schema_path = 'main';
+-- run
+
+-- ===================================
+-- table_info edge cases
+-- ===================================
+
+-- Table with many columns
+CREATE TABLE wide_table (
+	a INTEGER PRIMARY KEY,
+	b TEXT,
+	c REAL,
+	d INTEGER,
+	e TEXT,
+	f REAL
+);
+
+SELECT count(*) as cnt FROM table_info('wide_table');
+→ [{"cnt": 6}]
+
+-- Verify column order
+SELECT name FROM table_info('wide_table') ORDER BY cid;
+→ [{"name": "a"}, {"name": "b"}, {"name": "c"}, {"name": "d"}, {"name": "e"}, {"name": "f"}]
+
+DROP TABLE wide_table;
+
+-- Table with no non-PK columns
+CREATE TABLE pk_only (id INTEGER PRIMARY KEY);
+INSERT INTO pk_only VALUES (1), (2), (3);
+
+SELECT * FROM pk_only ORDER BY id;
+→ [{"id": 1}, {"id": 2}, {"id": 3}]
+
+-- table_info on single-column table
+SELECT name, type, pk FROM table_info('pk_only') ORDER BY cid;
+→ [{"name": "id", "type": "INTEGER", "pk": 1}]
+
+DROP TABLE pk_only;
+
+-- ===================================
+-- Views
+-- ===================================
+
+CREATE TABLE v_source (id INTEGER PRIMARY KEY, name TEXT, active INTEGER);
+INSERT INTO v_source VALUES (1, 'Alice', 1), (2, 'Bob', 0), (3, 'Charlie', 1);
+
+CREATE VIEW active_items AS SELECT id, name FROM v_source WHERE active = 1;
+
+SELECT * FROM active_items ORDER BY id;
+→ [{"id": 1, "name": "Alice"}, {"id": 3, "name": "Charlie"}]
+
+-- Drop and recreate view
+DROP VIEW active_items;
+
+CREATE VIEW active_items AS SELECT id, name FROM v_source WHERE active = 1;
+
+SELECT * FROM active_items ORDER BY id;
+→ [{"id": 1, "name": "Alice"}, {"id": 3, "name": "Charlie"}]
+
+DROP VIEW active_items;
+DROP TABLE v_source;
+
+-- ===================================
+-- DROP TABLE IF EXISTS
+-- ===================================
+
+-- Should not error on non-existent table
+DROP TABLE IF EXISTS nonexistent_table;
+-- run
+
+-- Should work on existing table
+CREATE TABLE temp_drop (id INTEGER PRIMARY KEY);
+DROP TABLE IF EXISTS temp_drop;
+-- run
+
+-- Verify it was dropped
+SELECT * FROM temp_drop;
+-- error: not found
+
+-- ===================================
+-- Schema with assertions
+-- ===================================
+
+declare schema validated {
+	table accounts {
+		id INTEGER PRIMARY KEY,
+		balance REAL NOT NULL
+	}
+	assertion positive_balance check (not exists (select 1 from validated.accounts where balance < 0))
+}
+
+apply schema validated;
+-- run
+
+INSERT INTO validated.accounts VALUES (1, 100.0), (2, 50.0);
+
+SELECT * FROM validated.accounts ORDER BY id;
+→ [{"id": 1, "balance": 100.0}, {"id": 2, "balance": 50.0}]
+
+-- Negative balance should violate assertion
+INSERT INTO validated.accounts VALUES (3, -10.0);
+-- error: assertion
+
+-- ===================================
+-- Window functions in queries (verify schema supports them)
+-- ===================================
+
+CREATE TABLE wf_data (id INTEGER PRIMARY KEY, grp TEXT, val INTEGER);
+INSERT INTO wf_data VALUES (1, 'A', 10), (2, 'A', 20), (3, 'B', 30), (4, 'B', 40), (5, 'B', 50);
+
+SELECT id, grp, val, row_number() over (partition by grp order by val) as rn FROM wf_data ORDER BY grp, val;
+→ [{"id": 1, "grp": "A", "val": 10, "rn": 1}, {"id": 2, "grp": "A", "val": 20, "rn": 2}, {"id": 3, "grp": "B", "val": 30, "rn": 1}, {"id": 4, "grp": "B", "val": 40, "rn": 2}, {"id": 5, "grp": "B", "val": 50, "rn": 3}]
+
+SELECT id, val, rank() over (order by val) as rnk FROM wf_data ORDER BY val;
+→ [{"id": 1, "val": 10, "rnk": 1}, {"id": 2, "val": 20, "rnk": 2}, {"id": 3, "val": 30, "rnk": 3}, {"id": 4, "val": 40, "rnk": 4}, {"id": 5, "val": 50, "rnk": 5}]
+
+SELECT id, val, dense_rank() over (order by val) as drnk FROM wf_data ORDER BY val;
+→ [{"id": 1, "val": 10, "drnk": 1}, {"id": 2, "val": 20, "drnk": 2}, {"id": 3, "val": 30, "drnk": 3}, {"id": 4, "val": 40, "drnk": 4}, {"id": 5, "val": 50, "drnk": 5}]
+
+SELECT id, grp, val, sum(val) over (partition by grp order by val) as running_sum FROM wf_data ORDER BY grp, val;
+→ [{"id": 1, "grp": "A", "val": 10, "running_sum": 10}, {"id": 2, "grp": "A", "val": 20, "running_sum": 30}, {"id": 3, "grp": "B", "val": 30, "running_sum": 30}, {"id": 4, "grp": "B", "val": 40, "running_sum": 70}, {"id": 5, "grp": "B", "val": 50, "running_sum": 120}]
+
+DROP TABLE wf_data;
+
+-- ===================================
+-- Cleanup
+-- ===================================
+
+DROP TABLE app1.customers;
+-- The assertion still names validated.accounts, so the table drop is refused
+-- until the rule goes first.
+DROP ASSERTION validated.positive_balance;
+DROP TABLE validated.accounts;
+DROP TABLE main_data;