@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/10.1.6-ddl-transaction-policy-index.sqllogic

@@ -0,0 +1,143 @@
+-- 10.1.6-ddl-transaction-policy-index.sqllogic — the `ddl_transaction_policy` gate over index DDL.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 10.1.4-ddl-transaction-policy: the gate treats every
+-- module-dispatching DDL statement alike (CREATE/DROP TABLE/INDEX, ALTER TABLE,
+-- CREATE/DROP/REFRESH MATERIALIZED VIEW), and 10.1.4 still proves each behavior with
+-- table, ALTER TABLE, materialized-view and `apply schema` statements. This file is
+-- the CREATE/DROP INDEX instance of the same cases, so a backend without standalone
+-- index DDL keeps the rest of the policy coverage.
+--
+-- Runs against every backend (memory, store). Neither declares
+-- ddlTransactionality='transactional', so strict refuses on both; the permissive
+-- section must behave identically on both. Each statement is its own block so an
+-- expected failure is attributed to exactly one statement.
+
+-- ===================================
+-- 1. Permissive default: create index inside a transaction is allowed
+-- ===================================
+
+create table perm_t (id integer primary key, v text);
+-- run
+begin;
+-- run
+insert into perm_t values (1, 'a');
+-- run
+create index perm_ix on perm_t (v);
+-- run
+insert into perm_t values (2, 'b');
+-- run
+commit;
+-- run
+
+select count(*) as cnt from perm_t;
+→ [{ "cnt": 2 }]
+
+drop index perm_ix;
+-- run
+
+drop table perm_t;
+-- run
+
+-- ===================================
+-- 2. strict: create index 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
+create index strict_ix on strict_t (v);
+-- 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 index was never created.
+select count(*) as cnt from strict_t;
+→ [{ "cnt": 3 }]
+
+-- ===================================
+-- 3. strict: the same statement is allowed OUTSIDE a transaction (autocommit)
+-- ===================================
+
+create index strict_ix on strict_t (v);
+-- run
+drop index strict_ix;
+-- run
+
+-- ===================================
+-- 4. strict: drop index is refused inside begin (index still present after)
+-- ===================================
+
+create index strict_ix2 on strict_t (v);
+-- run
+begin;
+-- run
+drop index strict_ix2;
+-- error: ddl_transaction_policy = strict
+rollback;
+-- run
+drop index strict_ix2;
+-- run
+
+-- ===================================
+-- 5. strict: a create-index 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 index sp_ix on sp_t (v);
+-- 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
+
+-- ===================================
+-- 6. Reset to permissive; index DDL inside a transaction works again
+-- ===================================
+
+pragma ddl_transaction_policy = 'permissive';
+-- run
+
+begin;
+-- run
+create index perm_again_ix on strict_t (v);
+-- run
+commit;
+-- run
+
+drop index perm_again_ix;
+-- run
+drop table strict_t;
+-- run

package/test/logic/10.1.7-create-table-default-type-check.sqllogic

@@ -0,0 +1,119 @@
+-- A literal DEFAULT must be convertible to its own column's declared type.
+--
+-- Before this, `create table t (n integer default 'abc')` was accepted silently,
+-- and the first INSERT relying on the default failed with a type-conversion error
+-- blaming the insert rather than the declaration. `foldDefaultToType` (the same
+-- helper ADD COLUMN / SET NOT NULL backfill already route through) now runs for
+-- every column at CREATE TABLE time, before the module creates any storage.
+
+-- ============================================================
+-- 1. An unconvertible literal default rejects CREATE TABLE, across type families
+-- ============================================================
+
+create table t_int (id integer primary key, n integer default 'abc');
+-- error: Type conversion failed
+
+select name from schema() where type = 'table' and name = 't_int';
+→ []
+
+create table t_real (id integer primary key, n real default 'x');
+-- error: Type conversion failed
+
+select name from schema() where type = 'table' and name = 't_real';
+→ []
+
+create table t_date (id integer primary key, d date default 'not-a-date');
+-- error:
+
+select name from schema() where type = 'table' and name = 't_date';
+→ []
+
+create table t_json (id integer primary key, j json default '{');
+-- error:
+
+select name from schema() where type = 'table' and name = 't_json';
+→ []
+
+-- ============================================================
+-- 2. Convertible literals are still accepted, and stored already converted
+-- ============================================================
+
+create table t_conv (id integer primary key, n integer default '7', r real default -123.0);
+insert into t_conv (id) values (1);
+select n, typeof(n) as tn, r, typeof(r) as tr from t_conv where id = 1;
+→ [{"n":7,"tn":"integer","r":-123,"tr":"integer"}]
+drop table t_conv;
+-- run
+
+-- ============================================================
+-- 3. Non-foldable defaults are untouched — deferred to write time exactly as before
+-- ============================================================
+
+-- A function call.
+create table t_fn (id integer primary key, n integer default (abs(-3)));
+insert into t_fn (id) values (1);
+select n from t_fn where id = 1;
+→ [{"n":3}]
+drop table t_fn;
+-- run
+
+-- A `new.<col>` reference to a sibling.
+create table t_newref (id integer primary key, base integer, doubled integer default (new.base * 2));
+insert into t_newref (id, base) values (1, 10);
+select doubled from t_newref where id = 1;
+→ [{"doubled":20}]
+drop table t_newref;
+-- run
+
+-- A mutation-context variable default — not a literal, folds to `undefined`, and
+-- stays deferred; must not be confused with a NULL default.
+create table t_ctx (id integer primary key, n integer default markup) using memory with context (markup integer);
+insert into t_ctx (id) with context markup = 42 values (1);
+select n from t_ctx where id = 1;
+→ [{"n":42}]
+drop table t_ctx;
+-- run
+
+-- ============================================================
+-- 4. NULL default is always acceptable, on any type, and is not confused with a
+-- non-foldable (deferred) default.
+-- ============================================================
+
+create table t_null (id integer primary key, n integer null default null, d date null default null);
+insert into t_null (id) values (1);
+select n, d from t_null where id = 1;
+→ [{"n":null,"d":null}]
+drop table t_null;
+-- run
+
+-- ============================================================
+-- 5. `any`-typed columns accept every literal — the fold must not start rejecting them.
+-- ============================================================
+
+create table t_any (id integer primary key, v any default 'abc');
+insert into t_any (id) values (1);
+select v from t_any where id = 1;
+→ [{"v":"abc"}]
+drop table t_any;
+-- run
+
+-- ============================================================
+-- 6. `apply schema` (declarative-schema DDL) routes through the same createTable
+-- guard — a migration carrying a bad default fails the migration rather than
+-- deploying it.
+-- ============================================================
+
+declare schema xd_bad {
+	table t_migrated {
+		id INTEGER PRIMARY KEY,
+		n INTEGER DEFAULT 'abc'
+	}
+}
+
+-- run
+
+apply schema xd_bad;
+-- error: Type conversion failed
+
+select name from schema() where type = 'table' and name = 't_migrated';
+→ []

package/test/logic/10.1.8-alter-add-check-existing-rows.sqllogic

@@ -0,0 +1,117 @@
+-- ALTER TABLE … ADD CONSTRAINT … CHECK validates the rows already in the table.
+--
+-- The store leg matters as much as the memory leg: the validation is the ENGINE's,
+-- run before the module is dispatched to (runtime/emit/add-constraint.ts), so both
+-- backends must answer identically and a rejected ADD must persist nothing (the
+-- store's addConstraint arm saves the table's DDL). Companion to the per-package
+-- conformance legs' tightening suites and to test/alter-add-constraint.spec.ts
+-- (memory; the full `new.` / `old.` / opt-out matrix).
+--
+-- Why this is a wrong-result guard and not tidiness: the optimizer treats a declared
+-- CHECK as a proven fact about every stored row and folds contradicting predicates
+-- away, so a grandfathered violator would vanish from `where n <= 0` while still
+-- being stored. Section 2 states the property that fold depends on.
+
+-- ===================================================================
+-- 1. A violating row rejects; the table is untouched; nothing enforces forward.
+-- ===================================================================
+
+create table AcV (id integer primary key, n integer null);
+insert into AcV values (1, -5), (2, 7);
+
+alter table AcV add constraint c_pos check (n > 0);
+-- error: CHECK constraint failed: c_pos
+
+select count(*) as k from check_constraint_info('AcV');
+→ [{"k":0}]
+
+insert into AcV values (3, -1);
+select id from AcV where n <= 0 order by id;
+→ [{"id":1},{"id":3}]
+
+-- ===================================================================
+-- 2. Once the table conforms the same ADD succeeds and enforces forward — and a
+--    query contradicting the CHECK agrees with the stored rows.
+-- ===================================================================
+
+delete from AcV where n <= 0;
+alter table AcV add constraint c_pos check (n > 0);
+select name from check_constraint_info('AcV');
+→ [{"name":"c_pos"}]
+
+insert into AcV values (4, 0);
+-- error: CHECK constraint failed: c_pos
+
+select count(*) as k from AcV where n <= 0;
+→ [{"k":0}]
+
+-- ===================================================================
+-- 3. NULL passes a CHECK, so a NULL row is not a violation.
+-- ===================================================================
+
+create table AcN (id integer primary key, n integer null);
+insert into AcN values (1, null);
+alter table AcN add constraint c check (n > 0);
+select name from check_constraint_info('AcN');
+→ [{"name":"c"}]
+
+-- ===================================================================
+-- 4. `new.<col>` names the stored row and is validated like the bare spelling; a
+--    conjunct referencing `old.<col>` is a transition rule about the previous row
+--    image — it cannot be judged from a row sitting still, so it is skipped without
+--    blocking the statement, while its `old.`-free siblings are still validated.
+-- ===================================================================
+
+create table AcQ (id integer primary key, n integer null, status text null);
+insert into AcQ values (1, -5, 'z');
+
+alter table AcQ add constraint c_new check (new.n > 0);
+-- error: CHECK constraint failed: c_new
+
+alter table AcQ add constraint c_old check (old.n is null or n >= old.n);
+select name from check_constraint_info('AcQ');
+→ [{"name":"c_old"}]
+
+alter table AcQ add constraint c_mix check ((old.id is null or id = old.id) and status in ('a', 'i'));
+-- error: CHECK constraint failed: c_mix
+
+update AcQ set status = 'a' where id = 1;
+alter table AcQ add constraint c_mix check ((old.id is null or id = old.id) and status in ('a', 'i'));
+select name from check_constraint_info('AcQ') order by name;
+→ [{"name":"c_mix"},{"name":"c_old"}]
+
+-- ===================================================================
+-- 5. A partial-mask CHECK is not a row invariant — a row can legally be stored in
+--    violation of it (inserted under an update-only one, updated under an
+--    insert-only one, anything under a delete-only one) — so existing rows owe it
+--    nothing, it is not validated, and the optimizer lifts nothing from it: the
+--    violator stays visible to the contradicting query.
+-- ===================================================================
+
+create table AcD (id integer primary key, n integer null);
+insert into AcD values (1, -5);
+alter table AcD add constraint c_del check on delete (n > 0);
+alter table AcD add constraint c_ins check on insert (n > 0);
+alter table AcD add constraint c_upd check on update (n > 0);
+select name from check_constraint_info('AcD') order by name;
+→ [{"name":"c_del"},{"name":"c_ins"},{"name":"c_upd"}]
+select id from AcD where n <= 0;
+→ [{"id":1}]
+
+-- ===================================================================
+-- 6. The ADD COLUMN sibling shares the scan: an inline `check (new.<col> …)` is a
+--    constraint rejection, not an unknown-column error, and the column is not added.
+-- ===================================================================
+
+create table AcC (id integer primary key);
+insert into AcC values (1);
+
+alter table AcC add column v integer default -1 check (new.v > 0);
+-- error: CHECK constraint '_check_v' violated by backfilled rows
+
+select name from table_info('AcC');
+→ [{"name":"id"}]
+
+alter table AcC add column v integer default 1 check (new.v > 0);
+insert into AcC values (2, 0);
+-- error: CHECK constraint failed: _check_v