@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/47-upsert.sqllogic

@@ -0,0 +1,255 @@
+-- 47-upsert.sqllogic - Testing UPSERT (ON CONFLICT) clauses
+
+-- === Setup ===
+
+DROP TABLE IF EXISTS upsert_test;
+CREATE TABLE upsert_test (
+    id INTEGER PRIMARY KEY,
+    name TEXT,
+    count INTEGER DEFAULT 1
+);
+
+-- === Basic DO NOTHING tests ===
+
+-- Insert a row
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'first', 10);
+SELECT * FROM upsert_test;
+→ [{"id":1,"name":"first","count":10}]
+
+-- ON CONFLICT DO NOTHING - should silently skip duplicate
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'duplicate', 99)
+ON CONFLICT DO NOTHING;
+SELECT * FROM upsert_test;
+→ [{"id":1,"name":"first","count":10}]
+
+-- Insert a new row (no conflict) with ON CONFLICT DO NOTHING
+INSERT INTO upsert_test (id, name, count) VALUES (2, 'second', 20)
+ON CONFLICT DO NOTHING;
+SELECT * FROM upsert_test ORDER BY id;
+→ [{"id":1,"name":"first","count":10},{"id":2,"name":"second","count":20}]
+
+-- === Basic DO UPDATE tests ===
+
+-- Update on conflict using NEW.* to reference proposed values
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'updated_name', 100)
+ON CONFLICT DO UPDATE SET name = NEW.name, count = NEW.count;
+SELECT * FROM upsert_test ORDER BY id;
+→ [{"id":1,"name":"updated_name","count":100},{"id":2,"name":"second","count":20}]
+
+-- Update on conflict using unqualified column (existing value)
+INSERT INTO upsert_test (id, name, count) VALUES (2, 'ignored', 999)
+ON CONFLICT DO UPDATE SET count = count + 1;
+SELECT * FROM upsert_test ORDER BY id;
+→ [{"id":1,"name":"updated_name","count":100},{"id":2,"name":"second","count":21}]
+
+-- === Increment pattern ===
+
+-- Classic UPSERT increment pattern: increment if exists, insert if not
+INSERT INTO upsert_test (id, name, count) VALUES (3, 'new_entry', 1)
+ON CONFLICT DO UPDATE SET count = count + 1;
+SELECT * FROM upsert_test WHERE id = 3;
+→ [{"id":3,"name":"new_entry","count":1}]
+
+-- Now increment the existing row
+INSERT INTO upsert_test (id, name, count) VALUES (3, 'new_entry', 1)
+ON CONFLICT DO UPDATE SET count = count + 1;
+SELECT * FROM upsert_test WHERE id = 3;
+→ [{"id":3,"name":"new_entry","count":2}]
+
+-- Another increment
+INSERT INTO upsert_test (id, name, count) VALUES (3, 'ignored', 999)
+ON CONFLICT DO UPDATE SET count = count + 1;
+SELECT * FROM upsert_test WHERE id = 3;
+→ [{"id":3,"name":"new_entry","count":3}]
+
+-- === DO UPDATE with excluded.* (PostgreSQL compatibility) ===
+
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'via_excluded', 500)
+ON CONFLICT DO UPDATE SET name = excluded.name, count = excluded.count;
+SELECT * FROM upsert_test WHERE id = 1;
+→ [{"id":1,"name":"via_excluded","count":500}]
+
+-- === DO UPDATE with mixed references ===
+
+-- Combine existing values with proposed values
+INSERT INTO upsert_test (id, name, count) VALUES (2, 'combined', 100)
+ON CONFLICT DO UPDATE SET name = name || '_' || NEW.name, count = count + NEW.count;
+SELECT * FROM upsert_test WHERE id = 2;
+→ [{"id":2,"name":"second_combined","count":121}]
+
+-- === DO UPDATE with WHERE condition ===
+
+-- Only update if condition is met (condition passes)
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'conditional', 600)
+ON CONFLICT DO UPDATE SET count = NEW.count WHERE count < 600;
+SELECT * FROM upsert_test WHERE id = 1;
+→ [{"id":1,"name":"via_excluded","count":600}]
+
+-- Only update if condition is met (condition fails - should skip update)
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'should_skip', 700)
+ON CONFLICT DO UPDATE SET count = NEW.count WHERE count < 100;
+SELECT * FROM upsert_test WHERE id = 1;
+→ [{"id":1,"name":"via_excluded","count":600}]
+
+-- === UPSERT with RETURNING ===
+
+-- DO NOTHING with RETURNING (returns nothing when conflict is skipped)
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'ignored', 999)
+ON CONFLICT DO NOTHING
+RETURNING id, name, count;
+→ []
+
+-- DO UPDATE with RETURNING
+INSERT INTO upsert_test (id, name, count) VALUES (1, 'returned', 700)
+ON CONFLICT DO UPDATE SET name = NEW.name, count = NEW.count
+RETURNING id, name, count;
+→ [{"id":1,"name":"returned","count":700}]
+
+-- Verify the update was applied
+SELECT * FROM upsert_test WHERE id = 1;
+→ [{"id":1,"name":"returned","count":700}]
+
+-- Insert without conflict with RETURNING
+INSERT INTO upsert_test (id, name, count) VALUES (10, 'new_row', 50)
+ON CONFLICT DO NOTHING
+RETURNING id, name;
+→ [{"id":10,"name":"new_row"}]
+
+-- === Multiple rows with UPSERT ===
+
+-- Insert multiple rows, some conflict, some don't
+INSERT INTO upsert_test (id, name, count) VALUES
+    (10, 'update_existing', 100),
+    (11, 'brand_new', 200)
+ON CONFLICT DO UPDATE SET count = NEW.count;
+SELECT * FROM upsert_test WHERE id IN (10, 11) ORDER BY id;
+→ [{"id":10,"name":"new_row","count":100},{"id":11,"name":"brand_new","count":200}]
+
+-- === Conflict target specification ===
+
+-- Create table with explicit conflict target
+DROP TABLE IF EXISTS upsert_target;
+CREATE TABLE upsert_target (
+    id INTEGER PRIMARY KEY,
+    email TEXT UNIQUE,
+    name TEXT
+);
+
+INSERT INTO upsert_target VALUES (1, 'a@test.com', 'Alice');
+SELECT * FROM upsert_target;
+→ [{"id":1,"email":"a@test.com","name":"Alice"}]
+
+-- Conflict on primary key (id)
+INSERT INTO upsert_target (id, email, name) VALUES (1, 'new@test.com', 'Updated')
+ON CONFLICT (id) DO UPDATE SET name = NEW.name;
+SELECT * FROM upsert_target;
+→ [{"id":1,"email":"a@test.com","name":"Updated"}]
+
+-- === Error cases ===
+
+-- Cannot use both OR clause and ON CONFLICT
+INSERT OR REPLACE INTO upsert_target (id, email, name) VALUES (1, 'test@test.com', 'Test')
+ON CONFLICT DO NOTHING;
+-- error: Cannot use both 'INSERT OR ...' and 'ON CONFLICT' in the same statement
+
+-- ON CONFLICT DO UPDATE assigning the same column twice is rejected (no silent
+-- last-wins). This path never routes through buildUpdateStmt, so it carries its
+-- own backstop mirroring the UPDATE side. See ticket
+-- insert-family-duplicate-column-targets-silent-last-wins.
+INSERT INTO upsert_target (id, email, name) VALUES (1, 'x@test.com', 'X')
+ON CONFLICT (id) DO UPDATE SET name = 'one', name = 'two';
+-- error: duplicate assignment
+
+-- the rejected upsert made no change (name keeps its pre-conflict value, not
+-- last-wins 'two' or 'one').
+SELECT id, name FROM upsert_target;
+→ [{"id":1,"name":"Updated"}]
+
+-- The duplicate-target guard is case-insensitive: `name` and `NAME` collide.
+INSERT INTO upsert_target (id, email, name) VALUES (1, 'x@test.com', 'X')
+ON CONFLICT (id) DO UPDATE SET name = 'one', NAME = 'two';
+-- error: duplicate assignment
+
+-- A legitimate DO UPDATE assigning two *distinct* columns still works — the
+-- guard keys on exact-name collision, never on distinct columns.
+INSERT INTO upsert_target (id, email, name) VALUES (1, 'x@test.com', 'X')
+ON CONFLICT (id) DO UPDATE SET email = 'multi@test.com', name = 'Multi';
+SELECT id, email, name FROM upsert_target;
+→ [{"id":1,"email":"multi@test.com","name":"Multi"}]
+
+-- === UPSERT expressions with subqueries (optimizer must see them as children) ===
+-- `DmlExecutorNode` exposes ON CONFLICT assignment/WHERE expressions as
+-- getChildren() so the optimizer can rewrite subqueries inside them just like any
+-- other plan node. See bug-dml-side-expressions-invisible-to-optimizer.
+
+DROP TABLE IF EXISTS upsert_src;
+CREATE TABLE upsert_src (id INTEGER PRIMARY KEY, v TEXT);
+INSERT INTO upsert_src VALUES (1, 'a'), (2, 'b'), (3, 'c');
+
+DROP TABLE IF EXISTS upsert_expr;
+CREATE TABLE upsert_expr (id INTEGER PRIMARY KEY, name TEXT, count INTEGER);
+INSERT INTO upsert_expr VALUES (1, 'first', 10);
+
+-- subquery in a DO UPDATE SET value
+INSERT INTO upsert_expr (id, name, count) VALUES (1, 'dup', 0)
+ON CONFLICT (id) DO UPDATE SET count = (SELECT COUNT(*) FROM upsert_src);
+SELECT id, count FROM upsert_expr WHERE id = 1;
+→ [{"id":1,"count":3}]
+
+-- subquery in the DO UPDATE WHERE clause: condition false leaves the row unchanged
+INSERT INTO upsert_expr (id, name, count) VALUES (1, 'dup2', 999)
+ON CONFLICT (id) DO UPDATE SET count = NEW.count WHERE (SELECT COUNT(*) FROM upsert_src) > 10;
+SELECT id, count FROM upsert_expr WHERE id = 1;
+→ [{"id":1,"count":3}]
+
+-- subquery in the DO UPDATE WHERE clause: condition true applies the update
+INSERT INTO upsert_expr (id, name, count) VALUES (1, 'dup3', 999)
+ON CONFLICT (id) DO UPDATE SET count = NEW.count WHERE (SELECT COUNT(*) FROM upsert_src) > 1;
+SELECT id, count FROM upsert_expr WHERE id = 1;
+→ [{"id":1,"count":999}]
+
+-- subquery correlated to excluded.<col> (the proposed/rejected row)
+INSERT INTO upsert_expr (id, name, count) VALUES (1, 'corr', 2)
+ON CONFLICT (id) DO UPDATE SET count = (SELECT COUNT(*) FROM upsert_src WHERE id <= excluded.count);
+SELECT id, count FROM upsert_expr WHERE id = 1;
+→ [{"id":1,"count":2}]
+
+-- subquery correlated to an unqualified column (the conflicting existing row, not NEW)
+INSERT INTO upsert_expr (id, name, count) VALUES (1, 'corr2', 999)
+ON CONFLICT (id) DO UPDATE SET count = (SELECT COUNT(*) FROM upsert_src WHERE id <= count);
+SELECT id, count FROM upsert_expr WHERE id = 1;
+→ [{"id":1,"count":2}]
+
+DROP TABLE upsert_expr;
+
+-- multi-clause ON CONFLICT: two conflict targets, each with its own subquery
+-- assignment and WHERE — exercises the child ordering/slicing across clauses.
+DROP TABLE IF EXISTS upsert_multi;
+CREATE TABLE upsert_multi (
+    id INTEGER PRIMARY KEY,
+    email TEXT UNIQUE,
+    tag TEXT
+);
+INSERT INTO upsert_multi VALUES (1, 'a@test.com', 'A'), (2, 'b@test.com', 'B');
+
+-- conflict lands on the `id` target — its clause fires, the `email` clause does not
+INSERT INTO upsert_multi (id, email, tag) VALUES (1, 'new@test.com', 'ignored')
+ON CONFLICT (id) DO UPDATE SET tag = (SELECT COUNT(*) FROM upsert_src) WHERE (SELECT COUNT(*) FROM upsert_src) > 0
+ON CONFLICT (email) DO UPDATE SET tag = 'email-match' WHERE (SELECT COUNT(*) FROM upsert_src) > 100;
+SELECT id, tag FROM upsert_multi WHERE id = 1;
+→ [{"id":1,"tag":"3"}]
+
+-- conflict lands on the `email` target instead — the `id` clause's WHERE (which
+-- would fail) never runs; the `email` clause fires
+INSERT INTO upsert_multi (id, email, tag) VALUES (99, 'b@test.com', 'ignored')
+ON CONFLICT (id) DO UPDATE SET tag = (SELECT COUNT(*) FROM upsert_src) WHERE (SELECT COUNT(*) FROM upsert_src) > 100
+ON CONFLICT (email) DO UPDATE SET tag = (SELECT COUNT(*) FROM upsert_src) WHERE (SELECT COUNT(*) FROM upsert_src) > 0;
+SELECT id, tag FROM upsert_multi WHERE email = 'b@test.com';
+→ [{"id":2,"tag":"3"}]
+
+DROP TABLE upsert_multi;
+DROP TABLE upsert_src;
+
+-- Clean up
+DROP TABLE upsert_test;
+DROP TABLE upsert_target;

package/test/logic/47.1-upsert-conflict-targets.sqllogic

@@ -0,0 +1,169 @@
+-- adapted from SQLite test/upsert2.test, test/upsert3.test, test/upsert4.test
+-- UPSERT advanced conflict-target scenarios beyond 47-upsert.sqllogic:
+-- composite UNIQUE targets, partial-target rejection, INSERT...AS alias,
+-- column-list assignment in DO UPDATE SET, UPSERT with CTE source.
+
+-- ===================================
+-- 1. ON CONFLICT on composite UNIQUE — full match required
+-- ===================================
+
+create table comp_u (k integer, v text, payload text, unique (k, v));
+
+insert into comp_u values (0, 'abcd', 'first');
+
+-- full target columns match — DO NOTHING silently skips duplicate
+insert into comp_u values (0, 'abcd', 'second') on conflict (k, v) do nothing;
+select count(*) as cnt from comp_u;
+→ [{"cnt":1}]
+
+-- reversed column order in target also matches the same UNIQUE constraint
+insert into comp_u values (0, 'abcd', 'third') on conflict (v, k) do nothing;
+select count(*) as cnt from comp_u;
+→ [{"cnt":1}]
+
+-- Quereus accepts partial conflict targets that match any UNIQUE involving the listed column(s)
+-- so the SQLite-strict "must error" assertions don't apply here; verify the rows are still skipped instead
+insert into comp_u values (0, 'abcd', 'fourth') on conflict (k) do nothing;
+insert into comp_u values (0, 'abcd', 'fifth') on conflict (v) do nothing;
+select count(*) as cnt from comp_u;
+→ [{"cnt":1}]
+
+drop table comp_u;
+
+-- ===================================
+-- 2. UPSERT DO UPDATE referencing existing vs. proposed value via excluded.col
+-- ===================================
+
+create table counter (id integer primary key, n integer);
+insert into counter values (1, 10);
+
+-- excluded.* refers to the proposed (rejected) row's values
+insert into counter values (1, 5)
+   on conflict (id) do update set n = counter.n + excluded.n;
+
+select id, n from counter where id = 1;
+→ [{"id":1,"n":15}]
+
+drop table counter;
+
+-- ===================================
+-- 3. UPSERT with explicit table alias: INSERT ... AS alias
+-- Alias provides a name for the existing row in DO UPDATE
+-- ===================================
+
+create table alias_t (id integer primary key, name text, count integer);
+insert into alias_t values (1, 'alice', 1);
+
+-- INSERT ... AS alias is not supported by Quereus's parser
+insert into alias_t as old values (1, 'updated', 100)
+   on conflict (id) do update set name = excluded.name, count = old.count + 1;
+-- error: Expected VALUES, SELECT, or DML
+
+drop table alias_t;
+
+-- ===================================
+-- 4. UPSERT with CTE as source
+-- ===================================
+
+create table cte_dst (id integer primary key, val integer);
+
+with src(id, val) as (select 1 as id, 100 as val union all select 2, 200)
+   insert into cte_dst (id, val) select id, val from src
+   on conflict (id) do update set val = excluded.val;
+
+select id, val from cte_dst order by id;
+→ [{"id":1,"val":100},{"id":2,"val":200}]
+
+-- second pass with CTE — forces conflict and update path
+with src(id, val) as (select 1 as id, 999 as val union all select 3, 300)
+   insert into cte_dst (id, val) select id, val from src
+   on conflict (id) do update set val = excluded.val;
+
+select id, val from cte_dst order by id;
+→ [{"id":1,"val":999},{"id":2,"val":200},{"id":3,"val":300}]
+
+drop table cte_dst;
+
+-- ===================================
+-- 5. UPSERT DO UPDATE WHERE — condition fails leaves row unchanged
+-- ===================================
+
+create table guarded (id integer primary key, n integer);
+insert into guarded values (1, 100);
+
+-- condition true: update applies
+insert into guarded values (1, 200) on conflict (id) do update set n = excluded.n where n < 150;
+select n from guarded where id = 1;
+→ [{"n":200}]
+
+-- condition false: row unchanged
+insert into guarded values (1, 999) on conflict (id) do update set n = excluded.n where n < 150;
+select n from guarded where id = 1;
+→ [{"n":200}]
+
+drop table guarded;
+
+-- ===================================
+-- 6. UPSERT DO UPDATE with column-list assignment from subquery
+-- ===================================
+
+create table dual_set (id integer primary key, a text, b text);
+insert into dual_set values (1, 'x', 'y');
+
+-- column-list SET assignment in DO UPDATE is not supported by the parser
+insert into dual_set values (1, 'ignored_a', 'ignored_b')
+   on conflict (id) do update set (a, b) = (select 'new_a', 'new_b');
+-- error: Expected column name
+
+drop table dual_set;
+
+-- ===================================
+-- 7. UPSERT on multi-row INSERT — mix of conflict and non-conflict rows
+-- ===================================
+
+create table multi (id integer primary key, name text, count integer);
+insert into multi values (1, 'first', 10);
+
+insert into multi (id, name, count) values
+   (1, 'updated_first', 100),
+   (2, 'second', 20),
+   (3, 'third', 30)
+on conflict (id) do update set count = excluded.count;
+
+select id, name, count from multi order by id;
+→ [{"id":1,"name":"first","count":100},{"id":2,"name":"second","count":20},{"id":3,"name":"third","count":30}]
+
+drop table multi;
+
+-- ===================================
+-- 8. ON CONFLICT (<target>) only suppresses conflicts on <target>
+-- A DO NOTHING clause must NOT swallow a conflict on a *different* unique
+-- constraint. With a PK plus a secondary UNIQUE, a clause targeting one of
+-- them aborts when the actual conflict is on the other.
+-- (ticket seed-secondary-unique-silently-skipped)
+-- ===================================
+
+create table scoped (id integer primary key, email text unique);
+insert into scoped values (1, 'a@x');
+
+-- Conflict is on the `email` UNIQUE (existing row has a different PK), but the
+-- clause targets `id` — so it must abort, not skip.
+insert into scoped values (2, 'a@x') on conflict (id) do nothing;
+-- error: UNIQUE constraint failed
+
+-- Symmetric: conflict is on the PK `id` (existing row has a different email),
+-- but the clause targets `email` — must abort, not skip.
+insert into scoped values (1, 'b@x') on conflict (email) do nothing;
+-- error: UNIQUE constraint failed
+
+-- The aborted inserts left no trace: still just the original row.
+select id, email from scoped order by id;
+→ [{"id":1,"email":"a@x"}]
+
+-- Idempotency control: a genuine PK conflict (same id, same email) targeting
+-- the PK is skipped silently — the value-comparison match still holds.
+insert into scoped values (1, 'a@x') on conflict (id) do nothing;
+select count(*) as cnt from scoped;
+→ [{"cnt":1}]
+
+drop table scoped;

package/test/logic/47.2-replace-and-or-clauses.sqllogic

@@ -0,0 +1,164 @@
+-- distilled from SQLite test/conflict.test (replace/or-clauses surface);
+-- replace.test does not exist upstream, but the ticket calls out
+-- "INSERT OR REPLACE / OR IGNORE / OR ABORT / OR FAIL / OR ROLLBACK —
+--  Quereus's conflict-resolution surface may differ. Pin it down per clause."
+-- Existing fixtures cover OR IGNORE / OR REPLACE on UNIQUE (102) and NOT NULL (43.1);
+-- this fills in the REPLACE-INTO keyword form, multi-row REPLACE, REPLACE+RETURNING,
+-- UPDATE OR REPLACE on UNIQUE, and OR FAIL / OR ROLLBACK / OR ABORT semantics
+-- with respect to surrounding transactional state.
+
+-- ===================================
+-- 1. Bare REPLACE statement is not supported (only INSERT OR REPLACE form)
+-- ===================================
+
+create table rk (id integer primary key, email text unique, name text);
+insert into rk values (1, 'a@x', 'Alice'), (2, 'b@x', 'Bob');
+
+replace into rk values (1, 'a@x', 'Alice2');
+-- error: Expected statement type
+
+drop table rk;
+
+-- ===================================
+-- 2. INSERT OR REPLACE multi-row VALUES — atomic per-row conflict resolution
+-- ===================================
+
+create table rm (id integer primary key, name text unique);
+insert into rm values (1, 'Alice'), (2, 'Bob');
+
+insert or replace into rm values (1, 'Alice-New'), (3, 'Carol');
+
+select id, name from rm order by id;
+→ [{"id":1,"name":"Alice-New"},{"id":2,"name":"Bob"},{"id":3,"name":"Carol"}]
+
+drop table rm;
+
+-- ===================================
+-- 3. REPLACE that resolves multiple existing rows via UNIQUE conflict on different cols
+-- ===================================
+
+create table rmm (id integer primary key, email text unique, phone text unique);
+insert into rmm values (1, 'a@x', '111'), (2, 'b@x', '222');
+
+-- new row conflicts on email with id=1 and phone with id=2 — both old rows are replaced
+insert or replace into rmm values (3, 'a@x', '222');
+select id from rmm order by id;
+→ [{"id":3}]
+
+drop table rmm;
+
+-- ===================================
+-- 4. REPLACE INTO with RETURNING
+-- ===================================
+
+create table rr (id integer primary key, val text);
+insert into rr values (1, 'old');
+
+insert or replace into rr values (1, 'new') returning id, val;
+→ [{"id":1,"val":"new"}]
+
+drop table rr;
+
+-- ===================================
+-- 5. UPDATE OR <action> is intentionally not supported
+-- ===================================
+-- SQLite-only syntax with no precedent in Postgres / SQL Server / MySQL / Oracle / ANSI.
+-- Per-statement conflict overrides on UPDATE are pinned closed; use schema-level
+-- ON CONFLICT defaults (column / table constraint clauses) or rewrite via
+-- WHERE NOT EXISTS / explicit DELETE+UPDATE in a transaction. See docs/sql.md §11.
+
+create table uor (id integer primary key, code text unique);
+insert into uor values (1, 'aaa'), (2, 'bbb');
+
+update or replace uor set code = 'aaa' where id = 2;
+-- error: Expected table name
+
+drop table uor;
+
+-- ===================================
+-- 6. INSERT OR ABORT (default) — violation aborts the statement entirely
+-- ===================================
+
+create table ab (id integer primary key, val text);
+insert into ab values (1, 'a');
+
+-- bulk insert with a duplicate PK in the middle aborts the entire statement
+insert or abort into ab values (2, 'b'), (1, 'dup'), (3, 'c');
+-- error: UNIQUE constraint failed
+
+-- nothing should have been inserted
+select count(*) as cnt from ab;
+→ [{"cnt":1}]
+
+drop table ab;
+
+-- ===================================
+-- 7. INSERT OR FAIL — earlier rows in the failing statement remain inserted
+-- ===================================
+
+create table fl (id integer primary key, val text);
+insert into fl values (5, 'pre');
+
+-- FAIL inserts rows that succeed before the violation, then halts
+insert or fail into fl values (1, 'a'), (2, 'b'), (5, 'dup'), (3, 'c');
+-- error: UNIQUE constraint failed
+
+-- INSERT OR FAIL leaves previously-successful rows inserted
+select id, val from fl order by id;
+→ [{"id":1,"val":"a"},{"id":2,"val":"b"},{"id":5,"val":"pre"}]
+
+drop table fl;
+
+-- ===================================
+-- 8. INSERT OR ROLLBACK — violation rolls back the enclosing transaction
+-- ===================================
+
+create table rb (id integer primary key, val text);
+insert into rb values (1, 'pre');
+-- run
+
+begin;
+   insert into rb values (10, 'committed_in_tx');
+   insert or rollback into rb values (1, 'dup');
+   -- error: UNIQUE constraint failed
+
+-- INSERT OR ROLLBACK auto-rolls-back the enclosing transaction; only the
+-- pre-tx insert remains.
+select id, val from rb order by id;
+→ [{"id":1,"val":"pre"}]
+
+drop table rb;
+
+-- ===================================
+-- 9. INSERT OR IGNORE on CHECK constraint — violating row silently skipped
+-- ===================================
+
+create table ck (id integer primary key, n integer check (n > 0));
+insert into ck values (1, 10);
+
+insert or ignore into ck values (2, -5);
+select count(*) as cnt from ck;
+→ [{"cnt":1}]
+
+-- valid follow-up insert succeeds
+insert or ignore into ck values (3, 30);
+select id, n from ck order by id;
+→ [{"id":1,"n":10},{"id":3,"n":30}]
+
+drop table ck;
+
+-- ===================================
+-- 10. INSERT OR REPLACE on CHECK — REPLACE does NOT mask CHECK violations
+-- ===================================
+
+create table ck2 (id integer primary key, n integer check (n > 0));
+insert into ck2 values (1, 10);
+
+-- REPLACE relaxes UNIQUE/PK conflicts but CHECK is always abort-only
+insert or replace into ck2 values (2, -5);
+-- error: CHECK
+
+select count(*) as cnt from ck2;
+→ [{"cnt":1}]
+
+drop table ck2;