@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/10.1.4-ddl-transaction-policy.sqllogic

@@ -0,0 +1,314 @@
+-- DDL transaction policy: the `ddl_transaction_policy` pragma and its strict gate.
+--
+-- `permissive` (the default) leaves DDL-in-transaction behavior exactly as it was.
+-- `strict` refuses a module-dispatching DDL statement (CREATE/DROP TABLE/INDEX,
+-- ALTER TABLE, CREATE/DROP/REFRESH MATERIALIZED VIEW) while an explicit transaction
+-- is open, because on memory and store
+-- the schema change would escape the transaction (survive rollback). The refusal
+-- fires before any dispatch or catalog mutation, so the open transaction stays
+-- fully usable afterward.
+--
+-- Runs against every backend (memory, store). Neither declares
+-- ddlTransactionality='transactional', so strict refuses on both; the permissive
+-- sections must behave identically on both. Each statement is its own block so an
+-- expected failure is attributed to exactly one statement.
+--
+-- The gate is verb-agnostic, and every case below is asserted with a table,
+-- ALTER TABLE, materialized-view or `apply schema` statement. The CREATE/DROP INDEX
+-- instance of the same cases lives in 10.1.6-ddl-transaction-policy-index, which
+-- needs standalone index DDL.
+
+-- ===================================
+-- 1. Permissive default: DDL inside a transaction is allowed (unchanged behavior)
+-- ===================================
+
+create table perm_t (id integer primary key, v text);
+-- run
+begin;
+-- run
+insert into perm_t values (1, 'a');
+-- run
+alter table perm_t add column w text null;
+-- run
+insert into perm_t values (2, 'b', null);
+-- run
+commit;
+-- run
+
+select count(*) as cnt from perm_t;
+→ [{ "cnt": 2 }]
+
+alter table perm_t drop column w;
+-- run
+
+-- ===================================
+-- 2. strict: alter table inside begin is refused; the transaction survives
+-- ===================================
+
+pragma ddl_transaction_policy = 'strict';
+-- run
+
+create table strict_t (id integer primary key, v text);
+-- run
+insert into strict_t values (1, 'a');
+-- run
+begin;
+-- run
+insert into strict_t values (2, 'b');
+-- run
+alter table strict_t add column w text null;
+-- error: ddl_transaction_policy = strict
+
+-- The refusal left the transaction open and usable: insert again and commit.
+insert into strict_t values (3, 'c');
+-- run
+commit;
+-- run
+
+-- Both buffered rows landed and the column was never added.
+select count(*) as cnt from strict_t;
+→ [{ "cnt": 3 }]
+
+-- ===================================
+-- 3. strict: the same statement is allowed OUTSIDE a transaction (autocommit)
+-- ===================================
+
+alter table strict_t add column w text null;
+-- run
+alter table strict_t drop column w;
+-- run
+
+-- ===================================
+-- 4. strict: alter table ... add constraint is refused inside begin
+-- ===================================
+
+begin;
+-- run
+alter table strict_t add constraint strict_u unique (v);
+-- error: ddl_transaction_policy = strict
+rollback;
+-- run
+
+-- ===================================
+-- 5. strict: drop table is refused inside begin (table still present after)
+-- ===================================
+
+create table strict_t2 (id integer primary key);
+-- run
+begin;
+-- run
+drop table strict_t2;
+-- error: ddl_transaction_policy = strict
+rollback;
+-- run
+drop table strict_t2;
+-- run
+
+-- ===================================
+-- 6. strict: create table is refused inside begin
+-- ===================================
+
+begin;
+-- run
+create table strict_t2 (id integer primary key);
+-- error: ddl_transaction_policy = strict
+rollback;
+-- run
+
+-- The refused create table left nothing behind; base data intact.
+select count(*) as cnt from strict_t;
+→ [{ "cnt": 3 }]
+
+-- ===================================
+-- 6b. strict: a refusal inside a savepoint leaves the savepoint usable
+-- ===================================
+
+create table sp_t (id integer primary key, v text);
+-- run
+insert into sp_t values (1, 'a');
+-- run
+begin;
+-- run
+savepoint sp1;
+-- run
+insert into sp_t values (2, 'b');
+-- run
+create table sp_t2 (id integer primary key);
+-- error: ddl_transaction_policy = strict
+
+-- The savepoint is still usable: roll back to it (undoing row 2), continue, commit.
+rollback to savepoint sp1;
+-- run
+insert into sp_t values (3, 'c');
+-- run
+commit;
+-- run
+
+select id from sp_t order by id;
+→ [{ "id": 1 }, { "id": 3 }]
+
+drop table sp_t;
+-- run
+
+-- ===================================
+-- 6c. strict: create materialized view is refused inside begin
+-- ===================================
+
+begin;
+-- run
+create materialized view strict_mv as select id, v from strict_t;
+-- error: ddl_transaction_policy = strict
+
+-- The refusal left the transaction open and usable.
+insert into strict_t values (4, 'd');
+-- run
+commit;
+-- run
+
+select count(*) as cnt from strict_t;
+→ [{ "cnt": 4 }]
+
+-- Nothing was materialized.
+drop materialized view strict_mv;
+-- error: no such materialized view
+
+-- A no-op `if exists` drop has no target to resolve, so the gate never fires.
+begin;
+-- run
+drop materialized view if exists strict_mv;
+-- run
+rollback;
+-- run
+
+-- ===================================
+-- 6d. strict: the same create is allowed OUTSIDE a transaction (autocommit)
+-- ===================================
+
+create materialized view strict_mv as select id, v from strict_t;
+-- run
+
+select count(*) as cnt from strict_mv;
+→ [{ "cnt": 4 }]
+
+-- `if not exists` does NOT skip the gate: like CREATE TABLE, the gate keys off the
+-- statement, not off whether it would have been a no-op. (DROP differs by design —
+-- it has no target to resolve a module from; see the `if exists` case in 6c.)
+begin;
+-- run
+create materialized view if not exists strict_mv as select id, v from strict_t;
+-- error: ddl_transaction_policy = strict
+rollback;
+-- run
+
+-- ===================================
+-- 6e. strict: refresh / drop materialized view are refused inside begin
+--     (REFRESH is gated too — its reshape arm dispatches module alterTable and
+--     both arms commit contents mid-transaction; see materialized-view.ts)
+-- ===================================
+
+begin;
+-- run
+refresh materialized view strict_mv;
+-- error: ddl_transaction_policy = strict
+
+-- A refusal inside a savepoint leaves the savepoint usable (6b, for the MV verbs).
+savepoint mv_sp;
+-- run
+insert into strict_t values (5, 'e');
+-- run
+drop materialized view strict_mv;
+-- error: ddl_transaction_policy = strict
+rollback to savepoint mv_sp;
+-- run
+rollback;
+-- run
+
+-- Both refusals left the MV intact and readable.
+select count(*) as cnt from strict_mv;
+→ [{ "cnt": 4 }]
+
+-- Outside a transaction both succeed.
+refresh materialized view strict_mv;
+-- run
+drop materialized view strict_mv;
+-- run
+
+-- ===================================
+-- 7. Reset to permissive; DDL inside a transaction works again
+-- ===================================
+
+pragma ddl_transaction_policy = 'permissive';
+-- run
+
+begin;
+-- run
+create table perm_again (id integer primary key);
+-- run
+commit;
+-- run
+
+drop table perm_again;
+-- run
+
+-- Materialized-view DDL inside a transaction is likewise allowed again.
+begin;
+-- run
+create materialized view perm_mv as select id, v from strict_t;
+-- run
+refresh materialized view perm_mv;
+-- run
+commit;
+-- run
+
+select count(*) as cnt from perm_mv;
+→ [{ "cnt": 4 }]
+
+begin;
+-- run
+drop materialized view perm_mv;
+-- run
+commit;
+-- run
+
+drop table strict_t;
+-- run
+drop table perm_t;
+-- run
+
+-- ===================================
+-- 8. strict + `apply schema`: a migration is NOT gated in autocommit (its generated
+--    DDL runs inside the engine's implicit transaction), but the same migration
+--    wrapped in an explicit begin trips the gate on the first gated statement.
+--    Runs last, against an otherwise-empty main schema, so the declaration below is
+--    the whole of main and the diff generates no drops.
+-- ===================================
+
+pragma ddl_transaction_policy = 'strict';
+-- run
+
+declare schema main {
+	table ap_t (id INTEGER PRIMARY KEY, x INTEGER NOT NULL)
+	materialized view ap_mv as select id, x from ap_t
+}
+
+-- run
+
+apply schema main;
+
+-- run
+
+insert into ap_t values (1, 10);
+-- run
+
+select x from ap_mv;
+→ [{ "x": 10 }]
+
+-- Dropping only the MV leaves one statement in the next migration: its re-create.
+drop materialized view ap_mv;
+-- run
+begin;
+-- run
+apply schema main;
+-- error: ddl_transaction_policy = strict
+rollback;
+-- run

package/test/logic/10.1.5-alter-add-constraint-minted-name-disambiguation.sqllogic

@@ -0,0 +1,219 @@
+-- ALTER-path minted constraint-name disambiguation.
+--
+-- The ALTER counterpart of 10.1.4 (which covers the CREATE TABLE mints). A
+-- constraint the user does not name gets an invented name, and that name is the
+-- handle `ALTER TABLE … DROP CONSTRAINT <name>` addresses — so it has to address
+-- exactly ONE constraint. Every ALTER spelling that mints a name therefore
+-- disambiguates against the names already on the table:
+--
+--   * `ADD FOREIGN KEY (...)`      → `_fk_<table>_<cols>`, `_<N>` suffix on collision
+--   * `ADD COLUMN … references …`  → same mint, same suffix
+--   * `ADD CHECK (...)`            → `check_<n>`, n bumped upward until free
+--
+-- `check_<n>` bumps its INDEX rather than taking a `_<N>` suffix (which would read
+-- `check_1_2`); n starts at the number of CHECKs already on the table, which is
+-- the historical spelling, so every non-colliding name is byte-identical to what
+-- the engine minted before (§5 pins that).
+--
+-- A constraint the USER names and that collides keeps being refused (§6) — that is
+-- identity, not a mint.
+--
+-- No `-- requires-capability:` directive, so this runs under both the memory
+-- module and the store module. The store leg matters: disambiguated names are
+-- persisted and must survive a reopen.
+
+pragma foreign_keys = true;
+
+-- ===================================================================
+-- 1. `ALTER TABLE … ADD FOREIGN KEY` onto a column that already carries an
+--    unnamed FK: minted `_fk_AmC_x_2`, each key addressable and each dropping
+--    only itself. (Before the fix both were `_fk_AmC_x`, so one DROP silently
+--    removed both and the orphan insert below was accepted.)
+-- ===================================================================
+
+create table AmP1 (x integer primary key);
+create table AmP2 (y integer primary key);
+create table AmC (id integer primary key, x integer null references AmP1(x));
+
+select name from foreign_key_info('AmC') order by name;
+→ [{"name":"_fk_AmC_x"}]
+
+alter table AmC add foreign key (x) references AmP2(y);
+select name, "to" from foreign_key_info('AmC') order by name;
+→ [{"name":"_fk_AmC_x","to":"x"},{"name":"_fk_AmC_x_2","to":"y"}]
+
+-- Both keys enforce, each under its own name (FK existence checks share the
+-- `CHECK constraint failed:` prefix — see runtime/row-constraints.ts).
+-- A value present in AmP1 but not AmP2 trips only the ALTER-added key…
+insert into AmP1 values (1);
+insert into AmC values (1, 1);
+-- error: CHECK constraint failed: _fk_AmC_x_2
+
+-- …a value present in AmP2 but not AmP1 trips only the CREATE-time key…
+insert into AmP2 values (2);
+insert into AmC values (1, 2);
+-- error: CHECK constraint failed: _fk_AmC_x
+
+-- …and a value present in both parents is accepted.
+insert into AmP1 values (7);
+insert into AmP2 values (7);
+insert into AmC values (1, 7);
+select count(*) as c from AmC;
+→ [{"c":1}]
+
+-- Dropping the CREATE-time key removes ONLY it.
+alter table AmC drop constraint _fk_AmC_x;
+select name from foreign_key_info('AmC');
+→ [{"name":"_fk_AmC_x_2"}]
+
+-- The ALTER-added key still enforces (1 ∉ AmP2) — the enforcement half of the
+-- defect, which a name-only assertion would miss.
+insert into AmC values (2, 1);
+-- error: CHECK constraint failed: _fk_AmC_x_2
+
+-- …while a value only AmP2 holds is now accepted (the dropped key no longer binds).
+insert into AmP2 values (9);
+insert into AmC values (3, 9);
+select count(*) as c from AmC;
+→ [{"c":2}]
+
+-- And the survivor is itself addressable by its disambiguated name.
+alter table AmC drop constraint _fk_AmC_x_2;
+select count(*) as c from foreign_key_info('AmC');
+→ [{"c":0}]
+insert into AmC values (4, 12345);
+select count(*) as c from AmC;
+→ [{"c":3}]
+
+-- ===================================================================
+-- 2. `ALTER TABLE … ADD COLUMN … references …`: two inline FKs on ONE new
+--    column mint `_fk_AcC_x` / `_fk_AcC_x_2`, exactly as the CREATE TABLE
+--    spelling of the same declaration does.
+-- ===================================================================
+
+create table AcP1 (x integer primary key);
+create table AcP2 (y integer primary key);
+create table AcC (id integer primary key);
+
+alter table AcC add column x integer null references AcP1(x) references AcP2(y);
+select name, "to" from foreign_key_info('AcC') order by name;
+→ [{"name":"_fk_AcC_x","to":"x"},{"name":"_fk_AcC_x_2","to":"y"}]
+
+insert into AcP1 values (3);
+insert into AcC values (1, 3);
+-- error: CHECK constraint failed: _fk_AcC_x_2
+
+alter table AcC drop constraint _fk_AcC_x_2;
+insert into AcC values (1, 3);
+select count(*) as c from AcC;
+→ [{"c":1}]
+
+-- ===================================================================
+-- 3. ADD COLUMN revert drops by the name the module actually stored.
+--
+--    The engine pre-builds each inline FK (to reject a collation conflict before
+--    the module call) and remembers that FK's name as the one to hand back if a
+--    LATER inline constraint fails. If the engine's mint and the module's mint
+--    disambiguated against different sets, the revert would drop a name that was
+--    never installed and strand the real constraint on a column that is about to
+--    disappear — under a DISAMBIGUATED name, which is exactly the case this file
+--    creates. Here the first inline FK installs and the second is rejected, so the
+--    whole ALTER must leave the table exactly as it was.
+--
+--    The rejection trigger is a child/parent COLLATION conflict rather than an
+--    existing-row FK orphan, because the collation check is engine-side and
+--    unconditional, so this case runs identically on every backend. (The orphan
+--    trigger does not fire on the Lamina backend, which replays this corpus —
+--    tracked in that repo as `bug-add-constraint-admits-orphan-rows`.) The first
+--    FK's parent column has a DEFAULTED binary collation, which is the engine
+--    floor and resolves against the child's declared NOCASE; the second FK's
+--    parent DECLARES binary, and two declarations at the same rank conflict.
+-- ===================================================================
+
+create table RvP1 (id integer primary key, x text unique);
+create table RvP2 (id integer primary key, y text collate binary unique);
+create table RvC (id integer primary key);
+insert into RvC values (1);
+
+alter table RvC add column x text null collate nocase references RvP1(x) references RvP2(y);
+-- error: conflicting collations
+
+-- Column gone, both keys gone — nothing stranded.
+select count(*) as c from table_info('RvC');
+→ [{"c":1}]
+select count(*) as c from foreign_key_info('RvC');
+→ [{"c":0}]
+
+-- ===================================================================
+-- 4. `ALTER TABLE … ADD CHECK (...)`: a drop shrinks the CHECK count, so the
+--    next unnamed add would re-mint a LIVE `check_<n>`. The index is bumped
+--    past it instead. (Before the fix the third add below re-minted `check_1`,
+--    and `alter table Ckm drop constraint check_1` then switched off BOTH the
+--    `a < 100` rule and the `a <> 7` rule.)
+-- ===================================================================
+
+create table Ckm (id integer primary key, a integer null);
+
+alter table Ckm add check (a > 0);
+alter table Ckm add check (a < 100);
+select name from check_constraint_info('Ckm') order by name;
+→ [{"name":"check_0"},{"name":"check_1"}]
+
+alter table Ckm drop constraint check_0;
+alter table Ckm add check (a <> 7);
+select name from check_constraint_info('Ckm') order by name;
+→ [{"name":"check_1"},{"name":"check_2"}]
+
+-- Both survivors enforce, each under its own name.
+insert into Ckm values (1, 200);
+-- error: check_1
+
+insert into Ckm values (2, 7);
+-- error: check_2
+
+-- The dropped lower bound no longer binds.
+insert into Ckm values (3, -1);
+select count(*) as c from Ckm;
+→ [{"c":1}]
+
+-- Dropping `check_1` releases ONLY the upper bound; `check_2` still rejects 7.
+alter table Ckm drop constraint check_1;
+insert into Ckm values (4, 200);
+select count(*) as c from Ckm;
+→ [{"c":2}]
+
+insert into Ckm values (5, 7);
+-- error: check_2
+
+-- ===================================================================
+-- 5. Non-colliding mints are unchanged (pins the compatibility property).
+--
+--    The index is seeded from the CHECK COUNT, not from the lowest free index,
+--    so a table whose existing CHECK is user-named still mints `check_1` for the
+--    first unnamed add — byte-identical to the historical spelling, even though
+--    `check_0` happens to be free.
+-- ===================================================================
+
+create table CkU (id integer primary key, a integer null, constraint ck_user check (a > -100));
+alter table CkU add check (a > 0);
+select name from check_constraint_info('CkU') order by name;
+→ [{"name":"check_1"},{"name":"ck_user"}]
+
+-- A lone ALTER-added FK onto a table with no constraint of that name keeps the
+-- bare mint.
+create table SoloP (x integer primary key);
+create table SoloC (id integer primary key, x integer null);
+alter table SoloC add foreign key (x) references SoloP(x);
+select name from foreign_key_info('SoloC');
+→ [{"name":"_fk_SoloC_x"}]
+
+-- ===================================================================
+-- 6. A name the USER writes is identity, not a mint: a collision is still
+--    refused rather than disambiguated.
+-- ===================================================================
+
+alter table CkU add constraint ck_user check (a < 5);
+-- error: already exists
+
+select count(*) as c from check_constraint_info('CkU');
+→ [{"c":2}]

package/test/logic/10.1.5-create-index-lifecycle.sqllogic

@@ -0,0 +1,72 @@
+-- 10.1.5-create-index-lifecycle.sqllogic — CREATE INDEX lifecycle and DDL error paths.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 10.1-ddl-lifecycle: that file's subject is the generic DDL lifecycle
+-- (create → insert → verify → drop, IF NOT EXISTS / IF EXISTS, ALTER, schema-vs-
+-- transaction interaction, multi-table sequences) and its remaining error cases are
+-- all table-shaped. Only these sections need standalone index DDL, so they move here.
+--
+-- Subject: creating, re-creating (IF NOT EXISTS), listing and dropping indexes, plus
+-- the DDL rejections — unknown table, unknown column, duplicate index name.
+
+-- ===================================
+-- 1. CREATE INDEX Lifecycle
+-- ===================================
+
+create table idx_lifecycle (id integer primary key, name text, score integer);
+
+insert into idx_lifecycle values
+	(1, 'Alice', 90),
+	(2, 'Bob', 80),
+	(3, 'Charlie', 95);
+
+-- Create an index
+create index idx_lc_score on idx_lifecycle (score);
+
+-- Queries should still work with the index present
+select name from idx_lifecycle where score > 85 order by name;
+→ [{"name": "Alice"}, {"name": "Charlie"}]
+
+-- CREATE INDEX IF NOT EXISTS on existing index is a no-op
+create index if not exists idx_lc_score on idx_lifecycle (score);
+
+-- Create a second index on a different column
+create index idx_lc_name on idx_lifecycle (name);
+
+select name from idx_lifecycle where name = 'Bob';
+→ [{"name": "Bob"}]
+
+-- Verify indexes are visible in schema()
+select name from schema() where type = 'index' and tbl_name = 'idx_lifecycle' order by name;
+→ [{"name": "idx_lc_name"}, {"name": "idx_lc_score"}]
+
+-- Clean up
+drop table idx_lifecycle;
+
+-- ===================================
+-- 2. CREATE INDEX error cases
+-- ===================================
+-- (the table-shaped rejections — unknown table, duplicate column name, dropping a
+--  missing table — stay in 10.1-ddl-lifecycle § 5)
+
+-- 2a. CREATE INDEX on non-existent table
+create index idx_bad on no_such_table (col);
+-- error: no such table
+
+-- 2b. CREATE INDEX on non-existent column
+create table idx_err (id integer primary key, name text);
+
+create index idx_bad_col on idx_err (missing_col);
+-- error: not found
+
+drop table idx_err;
+
+-- 2c. Duplicate index name without IF NOT EXISTS
+create table idx_dup_test (id integer primary key, val integer);
+create index idx_dup on idx_dup_test (val);
+
+create index idx_dup on idx_dup_test (val);
+-- error: already exists
+
+drop table idx_dup_test;