@quereus/quereus 4.20.1 → 4.20.3

package/test/logic/47.2.1-pk-replace-secondary-unique.sqllogic

@@ -0,0 +1,374 @@
+-- A write that collides on the PRIMARY KEY and resolves it by REPLACE must still
+-- enforce every other UNIQUE constraint, each under its own conflict action
+-- (statement OR > per-constraint default > ABORT). Expected results match
+-- SQLite except cases G and M2, which pin a deliberate divergence (see
+-- docs/sql-dml.md § Conflict Resolution): the row displaced at the PK counts as
+-- already gone, so its UNIQUE values are free for the new row. Previously the
+-- memory table wrote the row and returned on the PK-REPLACE branch, leaving a
+-- secondary UNIQUE column duplicated.
+
+-- ===================================
+-- A. INSERT OR REPLACE — PK and secondary UNIQUE conflicts both resolved by deletion
+-- ===================================
+
+create table pr_a (id integer primary key, v text unique);
+create table pr_a_child (id integer primary key, parent_id integer references pr_a(id) on delete cascade);
+insert into pr_a values (1, 'a'), (2, 'b');
+insert into pr_a_child values (20, 2);
+
+insert or replace into pr_a values (1, 'b');
+
+select * from pr_a order by id;
+→ [{"id":1,"v":"b"}]
+
+-- The row evicted on the secondary UNIQUE (id=2) runs the full delete pipeline.
+select * from pr_a_child;
+→ []
+
+drop table pr_a_child;
+drop table pr_a;
+
+-- ===================================
+-- B. PK-level REPLACE; UNIQUE keeps its own default (ABORT) → error
+-- ===================================
+
+create table pr_b (id integer primary key on conflict replace, v text unique);
+insert into pr_b values (1, 'a'), (2, 'b');
+
+insert into pr_b values (1, 'b');
+-- error: UNIQUE constraint failed
+
+select * from pr_b order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+drop table pr_b;
+
+-- ===================================
+-- C. Key-changing UPDATE under PK-level REPLACE, UNIQUE default ABORT → error, table unchanged
+-- ===================================
+
+create table pr_c (id integer primary key on conflict replace, v text unique);
+insert into pr_c values (1, 'a'), (2, 'b'), (3, 'c');
+
+update pr_c set id = 1, v = 'b' where id = 3;
+-- error: UNIQUE constraint failed
+
+select * from pr_c order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"},{"id":3,"v":"c"}]
+
+drop table pr_c;
+
+-- ===================================
+-- D. Key-changing UPDATE, both constraints REPLACE
+-- ===================================
+
+create table pr_d (id integer primary key on conflict replace, v text unique on conflict replace);
+insert into pr_d values (1, 'a'), (2, 'b'), (3, 'c');
+
+update pr_d set id = 1, v = 'b' where id = 3;
+
+select * from pr_d order by id;
+→ [{"id":1,"v":"b"}]
+
+drop table pr_d;
+
+-- ===================================
+-- E. INSERT, both constraints REPLACE
+-- ===================================
+
+create table pr_e (id integer primary key on conflict replace, v text unique on conflict replace);
+insert into pr_e values (1, 'a'), (2, 'b');
+
+insert into pr_e values (1, 'b');
+
+select * from pr_e order by id;
+→ [{"id":1,"v":"b"}]
+
+drop table pr_e;
+
+-- ===================================
+-- F. PK-level REPLACE, UNIQUE IGNORE — the secondary IGNORE skips the whole insert
+-- ===================================
+
+create table pr_f (id integer primary key on conflict replace, v text unique on conflict ignore);
+insert into pr_f values (1, 'a'), (2, 'b');
+
+insert into pr_f values (1, 'b');
+
+select * from pr_f order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+drop table pr_f;
+
+-- ===================================
+-- G. PK REPLACE whose new value equals the replaced row's own value — no self-conflict
+--    (SQLite reports a UNIQUE error here: it checks v against the not-yet-displaced row)
+-- ===================================
+
+create table pr_g (id integer primary key on conflict replace, v text unique, w text);
+insert into pr_g values (1, 'a', 'x'), (2, 'b', 'y');
+
+insert into pr_g values (1, 'a', 'z');
+
+select * from pr_g order by id;
+→ [{"id":1,"v":"a","w":"z"},{"id":2,"v":"b","w":"y"}]
+
+drop table pr_g;
+
+-- ===================================
+-- H. Same as A inside an explicit transaction, rows written earlier in that transaction
+-- ===================================
+
+create table pr_h (id integer primary key, v text unique);
+insert into pr_h values (1, 'a');
+
+begin;
+insert into pr_h values (2, 'b');
+insert or replace into pr_h values (1, 'b');
+select * from pr_h order by id;
+→ [{"id":1,"v":"b"}]
+commit;
+
+select * from pr_h order by id;
+→ [{"id":1,"v":"b"}]
+
+drop table pr_h;
+
+-- ===================================
+-- I. Row at the replaced PK written earlier in the transaction; the secondary
+--    UNIQUE conflict is a committed row
+-- ===================================
+
+create table pr_i (id integer primary key, v text unique);
+insert into pr_i values (2, 'b');
+
+begin;
+insert into pr_i values (1, 'a');
+insert or replace into pr_i values (1, 'b');
+select * from pr_i order by id;
+→ [{"id":1,"v":"b"}]
+commit;
+
+select * from pr_i order by id;
+→ [{"id":1,"v":"b"}]
+
+drop table pr_i;
+
+-- ===================================
+-- J. PK-level REPLACE, UNIQUE default ABORT, every row written in the transaction
+-- ===================================
+
+create table pr_j (id integer primary key on conflict replace, v text unique);
+
+begin;
+insert into pr_j values (1, 'a'), (2, 'b');
+insert into pr_j values (1, 'b');
+-- error: UNIQUE constraint failed
+select * from pr_j order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+commit;
+
+select * from pr_j order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+drop table pr_j;
+
+-- ===================================
+-- K. PK-level REPLACE, UNIQUE default ABORT; row at the replaced PK written in the
+--    transaction, the secondary conflict is a committed row
+-- ===================================
+
+create table pr_k (id integer primary key on conflict replace, v text unique);
+insert into pr_k values (2, 'b');
+
+begin;
+insert into pr_k values (1, 'a');
+insert into pr_k values (1, 'b');
+-- error: UNIQUE constraint failed
+commit;
+
+select * from pr_k order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+drop table pr_k;
+
+-- ===================================
+-- L. Key-changing UPDATE inside a transaction over rows written in that transaction
+-- ===================================
+
+create table pr_l (id integer primary key on conflict replace, v text unique);
+create table pr_l2 (id integer primary key on conflict replace, v text unique on conflict replace);
+
+begin;
+insert into pr_l values (1, 'a'), (2, 'b'), (3, 'c');
+update pr_l set id = 1, v = 'b' where id = 3;
+-- error: UNIQUE constraint failed
+select * from pr_l order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"},{"id":3,"v":"c"}]
+
+insert into pr_l2 values (1, 'a'), (2, 'b'), (3, 'c');
+update pr_l2 set id = 1, v = 'b' where id = 3;
+select * from pr_l2 order by id;
+→ [{"id":1,"v":"b"}]
+commit;
+
+select * from pr_l order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"},{"id":3,"v":"c"}]
+select * from pr_l2 order by id;
+→ [{"id":1,"v":"b"}]
+
+drop table pr_l2;
+drop table pr_l;
+
+-- ===================================
+-- M. Key-changing UPDATE onto an occupied PK; the moving row keeps its own UNIQUE
+--    value — neither the slot it vacates nor the displaced row may self-conflict
+-- ===================================
+
+create table pr_m (id integer primary key on conflict replace, v text unique);
+insert into pr_m values (1, 'a'), (2, 'b'), (3, 'c');
+
+update pr_m set id = 1 where id = 3;
+
+select * from pr_m order by id;
+→ [{"id":1,"v":"c"},{"id":2,"v":"b"}]
+
+-- M2. The displaced row's own UNIQUE value is free for the mover to take
+--     (SQLite reports a UNIQUE error here, as in G).
+update pr_m set id = 2, v = 'b' where id = 1;
+
+select * from pr_m order by id;
+→ [{"id":2,"v":"b"}]
+
+drop table pr_m;
+
+-- ===================================
+-- N. Composite primary key — PK REPLACE plus secondary UNIQUE, insert and key-changing update
+-- ===================================
+
+create table pr_n (a integer, b integer, v text unique on conflict replace, primary key (a, b) on conflict replace);
+insert into pr_n values (1, 1, 'x'), (1, 2, 'y'), (2, 1, 'z');
+
+insert or replace into pr_n values (1, 1, 'y');
+
+select * from pr_n order by a, b;
+→ [{"a":1,"b":1,"v":"y"},{"a":2,"b":1,"v":"z"}]
+
+update pr_n set b = 1, a = 1 where a = 2 and b = 1;
+
+select * from pr_n order by a, b;
+→ [{"a":1,"b":1,"v":"z"}]
+
+update pr_n set a = 3 where a = 1 and b = 1;
+
+select * from pr_n order by a, b;
+→ [{"a":3,"b":1,"v":"z"}]
+
+drop table pr_n;
+
+-- ===================================
+-- O. Both channels on one write: the PK-replaced row and the UNIQUE-evicted row
+--    each cascade to their own children
+-- ===================================
+
+create table pr_o (id integer primary key, v text unique);
+create table pr_o_child (id integer primary key, parent_id integer references pr_o(id) on delete cascade);
+insert into pr_o values (1, 'a'), (2, 'b'), (3, 'c');
+insert into pr_o_child values (10, 1), (20, 2), (30, 3);
+
+insert or replace into pr_o values (1, 'b');
+
+select * from pr_o order by id;
+→ [{"id":1,"v":"b"},{"id":3,"v":"c"}]
+
+select * from pr_o_child order by id;
+→ [{"id":30,"parent_id":3}]
+
+drop table pr_o_child;
+drop table pr_o;
+
+-- ===================================
+-- P. Same-PK UPDATE of a row written earlier in the transaction onto a committed
+--    row's UNIQUE value — UNIQUE default ABORT → error, nothing reaches the commit
+-- ===================================
+
+create table pr_p (id integer primary key, v text unique);
+insert into pr_p values (2, 'b');
+
+begin;
+insert into pr_p values (1, 'a');
+update pr_p set v = 'b' where id = 1;
+-- error: UNIQUE constraint failed
+select * from pr_p order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+commit;
+
+select * from pr_p order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+drop table pr_p;
+
+-- ===================================
+-- Q. Same-PK UPDATE under a PK-level REPLACE, rows written in the transaction — the
+--    PK's action does not apply to the UNIQUE, which keeps its default ABORT
+-- ===================================
+
+create table pr_q (id integer primary key on conflict replace, v text unique);
+
+begin;
+insert into pr_q values (1, 'a'), (2, 'b');
+update pr_q set v = 'b' where id = 1;
+-- error: UNIQUE constraint failed
+commit;
+
+select * from pr_q order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+drop table pr_q;
+
+-- ===================================
+-- R. Same-PK UPDATE, UNIQUE IGNORE, conflict with a committed row — the update is
+--    skipped and the row written in the transaction survives the commit
+-- ===================================
+
+create table pr_r (id integer primary key, v text unique on conflict ignore);
+insert into pr_r values (2, 'b');
+
+begin;
+insert into pr_r values (1, 'a');
+update pr_r set v = 'b' where id = 1;
+select * from pr_r order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+commit;
+
+select * from pr_r order by id;
+→ [{"id":1,"v":"a"},{"id":2,"v":"b"}]
+
+drop table pr_r;
+
+-- ===================================
+-- S. Same-PK UPDATE, UNIQUE REPLACE, conflict with a committed row — the committed
+--    row is evicted through the full delete pipeline (its child cascades)
+-- ===================================
+
+create table pr_s (id integer primary key, v text unique on conflict replace);
+create table pr_s_child (id integer primary key, parent_id integer references pr_s(id) on delete cascade);
+insert into pr_s values (2, 'b');
+insert into pr_s_child values (20, 2);
+
+begin;
+insert into pr_s values (1, 'a');
+update pr_s set v = 'b' where id = 1;
+select * from pr_s order by id;
+→ [{"id":1,"v":"b"}]
+select * from pr_s_child;
+→ []
+commit;
+
+select * from pr_s order by id;
+→ [{"id":1,"v":"b"}]
+select * from pr_s_child;
+→ []
+
+drop table pr_s_child;
+drop table pr_s;

package/test/logic/47.3-engine-or-fail.sqllogic

@@ -0,0 +1,122 @@
+-- INSERT OR FAIL combined with engine-level constraints (NOT NULL / CHECK).
+-- The 47.2 case 7 covers OR FAIL + UNIQUE; this fills in the engine-level
+-- constraints so we know the FAIL→commit-prior-rows path applies uniformly.
+
+-- ===================================
+-- 1. OR FAIL on NOT NULL violation — earlier rows remain
+-- ===================================
+
+create table t_nn (id integer primary key, name text);
+insert into t_nn values (10, 'pre');
+
+insert or fail into t_nn values (1, 'a'), (2, 'b'), (3, null), (4, 'd');
+-- error: NOT NULL
+
+select id, name from t_nn order by id;
+→ [{"id":1,"name":"a"},{"id":2,"name":"b"},{"id":10,"name":"pre"}]
+
+drop table t_nn;
+
+-- ===================================
+-- 2. OR FAIL on CHECK violation — earlier rows remain
+-- ===================================
+
+create table t_ck (id integer primary key, n integer check (n > 0));
+insert into t_ck values (10, 100);
+
+insert or fail into t_ck values (1, 1), (2, 2), (3, -1), (4, 4);
+-- error: CHECK
+
+select id, n from t_ck order by id;
+→ [{"id":1,"n":1},{"id":2,"n":2},{"id":10,"n":100}]
+
+drop table t_ck;
+
+-- ===================================
+-- 3. OR ROLLBACK on engine-level CHECK rolls back the enclosing transaction
+-- ===================================
+
+create table t_rb (id integer primary key, n integer check (n > 0));
+insert into t_rb values (1, 10);
+-- run
+
+begin;
+   insert into t_rb values (2, 20);
+   insert or rollback into t_rb values (3, -5);
+   -- error: CHECK
+
+-- The enclosing transaction was auto-rolled-back; only the pre-tx insert remains.
+select id, n from t_rb order by id;
+→ [{"id":1,"n":10}]
+
+drop table t_rb;
+
+-- ===================================
+-- 4. OR FAIL nested under a user-level SAVEPOINT — ROLLBACK TO must work
+-- ===================================
+-- The per-row OR FAIL savepoint (`__or_fail_N`) is created and released
+-- inside the bracket. After the bracket ends, the user-level savepoint
+-- stack must remain aligned with TxnMgr's. If the per-row create/release
+-- did not broadcast to connections (the bug this exercises), per-connection
+-- stacks would drift relative to TxnMgr and ROLLBACK TO sp would restore
+-- the wrong layer.
+
+create table t_sp (id integer primary key, name text);
+insert into t_sp values (10, 'pre');
+-- run
+
+begin;
+savepoint sp1;
+-- OR FAIL succeeds for all rows: per-row create/release brackets must
+-- compose cleanly with the surrounding user savepoint.
+insert or fail into t_sp values (1, 'a'), (2, 'b'), (3, 'c');
+select id, name from t_sp order by id;
+→ [{"id":1,"name":"a"},{"id":2,"name":"b"},{"id":3,"name":"c"},{"id":10,"name":"pre"}]
+
+-- ROLLBACK TO sp1: must undo all three OR-FAIL rows, leaving only `pre`.
+rollback to savepoint sp1;
+select id, name from t_sp order by id;
+→ [{"id":10,"name":"pre"}]
+
+-- Re-INSERT under the same sp1 to verify the stack is still well-formed.
+insert or fail into t_sp values (4, 'd'), (5, 'e');
+select id, name from t_sp order by id;
+→ [{"id":4,"name":"d"},{"id":5,"name":"e"},{"id":10,"name":"pre"}]
+
+release savepoint sp1;
+commit;
+
+select id, name from t_sp order by id;
+→ [{"id":4,"name":"d"},{"id":5,"name":"e"},{"id":10,"name":"pre"}]
+
+drop table t_sp;
+
+-- ===================================
+-- 5. OR FAIL whose middle row fails, nested under a SAVEPOINT
+-- ===================================
+-- When OR FAIL aborts mid-statement, the per-row __or_fail_N savepoint for
+-- the failing row is rolled back + released. Earlier rows commit. The
+-- surrounding sp1 must still be reachable for a follow-on rollback.
+
+create table t_spf (id integer primary key, n integer check (n > 0));
+insert into t_spf values (100, 99);
+-- run
+
+begin;
+savepoint sp1;
+insert or fail into t_spf values (1, 1), (2, 2), (3, -1), (4, 4);
+-- error: CHECK
+
+-- Rows 1,2 survive; 3,4 do not. Pre-row 100 also survives.
+select id, n from t_spf order by id;
+→ [{"id":1,"n":1},{"id":2,"n":2},{"id":100,"n":99}]
+
+-- The user-level sp1 is still aligned: rollback wipes the OR-FAIL survivors.
+rollback to savepoint sp1;
+select id, n from t_spf order by id;
+→ [{"id":100,"n":99}]
+
+release savepoint sp1;
+commit;
+
+drop table t_spf;

package/test/logic/47.3-upsert-conflict-target-collation.sqllogic

@@ -0,0 +1,139 @@
+-- ON CONFLICT (cols) DO UPDATE / DO NOTHING must match a conflict the targeted
+-- constraint *enforces* — a collation-equal conflict (NOCASE case-variant, RTRIM
+-- trailing-space) — and route it to the UPSERT arm instead of aborting with a
+-- UNIQUE error. Ticket bug-upsert-conflict-target-collation-match.
+-- Pre-fix, matchUpsertClause compared proposed vs stored by byte identity
+-- (sqlValueIdentical), so every collation-variant scenario below wrongly aborted.
+--
+-- The affinity-coercion corner ('1' vs stored INTEGER 1) lives in the sibling
+-- memory-only file 47.4-upsert-conflict-target-affinity.sqllogic — it exposes a
+-- separate isolation-layer defect under the store backend (see that file's header
+-- and fix/bug-store-isolation-upsert-affinity-coerced-pk).
+-- The index-derived-collation scenario (UNIQUE via a standalone `create unique
+-- index` with a per-column COLLATE) lives in the sibling file
+-- 47.3.1-upsert-conflict-index-derived-collation.sqllogic.
+
+-- ===================================
+-- 1. NOCASE single-column UNIQUE — DO UPDATE runs on a case-variant conflict.
+--    Proposed 'alice' collides with stored 'Alice' under NOCASE; the existing
+--    row is updated (a new row is NOT inserted, and no UNIQUE abort).
+-- ===================================
+
+create table nc_u (id integer primary key, name text collate nocase unique, hits integer);
+insert into nc_u values (1, 'Alice', 1);
+
+insert into nc_u values (2, 'alice', 99) on conflict (name) do update set hits = hits + 1;
+select id, name, hits from nc_u order by id;
+→ [{"id":1,"name":"Alice","hits":2}]
+
+-- ===================================
+-- 2. NOCASE DO NOTHING arm — a case-variant conflict is SKIPPED, not aborted.
+-- ===================================
+
+insert into nc_u values (3, 'ALICE', 5) on conflict (name) do nothing;
+select count(*) as cnt from nc_u;
+→ [{"cnt":1}]
+select id, name, hits from nc_u order by id;
+→ [{"id":1,"name":"Alice","hits":2}]
+
+-- Control: a genuinely different NOCASE value is NOT a conflict — it inserts.
+insert into nc_u values (4, 'Bob', 1) on conflict (name) do update set hits = hits + 1;
+select id, name, hits from nc_u order by id;
+→ [{"id":1,"name":"Alice","hits":2},{"id":4,"name":"Bob","hits":1}]
+
+drop table nc_u;
+
+-- ===================================
+-- 3. RTRIM UNIQUE — a trailing-space variant matches under RTRIM.
+-- ===================================
+
+create table rt_u (id integer primary key, code text collate rtrim unique, n integer);
+insert into rt_u values (1, 'abc', 10);
+
+insert into rt_u values (2, 'abc   ', 0) on conflict (code) do update set n = n + 1;
+select id, code, n from rt_u order by id;
+→ [{"id":1,"code":"abc","n":11}]
+
+drop table rt_u;
+
+-- ===================================
+-- 4. Byte-identical regression control + different-constraint-still-aborts.
+--    A BINARY key conflict still matches; a conflict on a DIFFERENT unique
+--    constraint than the one named still aborts (the fix must not widen matching).
+-- ===================================
+
+create table scoped2 (id integer primary key, email text unique);
+insert into scoped2 values (1, 'a@x');
+
+-- byte-identical PK conflict still skipped (no regression)
+insert into scoped2 values (1, 'a@x') on conflict (id) do nothing;
+select count(*) as cnt from scoped2;
+→ [{"cnt":1}]
+
+-- conflict is on `email` (different PK), but the clause targets `id` → abort
+insert into scoped2 values (2, 'a@x') on conflict (id) do nothing;
+-- error: UNIQUE constraint failed
+
+select id, email from scoped2 order by id;
+→ [{"id":1,"email":"a@x"}]
+
+drop table scoped2;
+
+-- ===================================
+-- 5. Composite target with per-column collations — each target column is
+--    compared under its OWN column's collation. `a` matches exactly, `b`
+--    matches under NOCASE.
+-- ===================================
+
+create table comp_coll (a integer, b text collate nocase, note text, unique (a, b));
+insert into comp_coll values (1, 'Xy', 'orig');
+
+insert into comp_coll values (1, 'XY', 'ignored') on conflict (a, b) do update set note = 'updated';
+select a, b, note from comp_coll order by a;
+→ [{"a":1,"b":"Xy","note":"updated"}]
+
+-- A composite where only `a` collides (different `b` under NOCASE) is NOT a
+-- conflict on (a, b) — it inserts as a new row.
+insert into comp_coll values (1, 'Zz', 'second') on conflict (a, b) do update set note = 'updated';
+select a, b, note from comp_coll order by b;
+→ [{"a":1,"b":"Xy","note":"updated"},{"a":1,"b":"Zz","note":"second"}]
+
+drop table comp_coll;
+
+-- ===================================
+-- 6. WHERE guard on DO UPDATE combined with a collation-variant conflict. The
+--    conflict is matched (NOCASE case-variant) so no new row inserts and no
+--    UNIQUE abort, but the WHERE guard governs whether the update runs — a
+--    false guard skips (DO NOTHING equivalent), a true guard updates.
+-- ===================================
+
+create table wg (id integer primary key, name text collate nocase unique, hits integer);
+insert into wg values (1, 'Kite', 5);
+
+-- guard false: conflict matched but update skipped, existing row untouched, no insert
+insert into wg values (2, 'KITE', 0) on conflict (name) do update set hits = hits + 1 where hits > 100;
+select id, name, hits from wg order by id;
+→ [{"id":1,"name":"Kite","hits":5}]
+
+-- guard true: same collation-variant conflict now updates
+insert into wg values (3, 'kite', 0) on conflict (name) do update set hits = hits + 1 where hits < 100;
+select id, name, hits from wg order by id;
+→ [{"id":1,"name":"Kite","hits":6}]
+
+drop table wg;
+
+-- ===================================
+-- 7. Multi-row INSERT mixing a collation-variant conflict row with clean rows
+--    under a single statement — the variant row routes to DO UPDATE, the clean
+--    rows insert, none abort.
+-- ===================================
+
+create table multi (id integer primary key, name text collate nocase unique, hits integer);
+insert into multi values (1, 'Ada', 1);
+
+insert into multi values (2, 'Bea', 1), (3, 'ADA', 0), (4, 'Cid', 1)
+  on conflict (name) do update set hits = hits + 10;
+select id, name, hits from multi order by id;
+→ [{"id":1,"name":"Ada","hits":11},{"id":2,"name":"Bea","hits":1},{"id":4,"name":"Cid","hits":1}]
+
+drop table multi;

package/test/logic/47.3.1-upsert-conflict-index-derived-collation.sqllogic

@@ -0,0 +1,25 @@
+-- Index-derived UNIQUE enforcement collation via ON CONFLICT upsert.
+--
+-- requires-capability: standalone-index-ddl
+--
+-- Carved out of 47.3-upsert-conflict-target-collation: every other section of
+-- 47.3 enforces UNIQUE through a column- or table-level constraint, but this
+-- scenario derives its UNIQUE from a standalone `create unique index` whose key
+-- expression carries a per-column COLLATE. Backends that retire first-class
+-- CREATE [UNIQUE] INDEX cannot run it, so it lives in its own file to keep 47.3's
+-- collation-variant upsert-matching subject portable across backends.
+--
+-- Subject: the enforcement collation is the INDEX's NOCASE, not the column's
+-- declared BINARY — so proposed 'HELLO' matches stored 'Hello' and routes to the
+-- DO UPDATE arm. Sibling: unique-enforcement-collation.spec.ts covers the same
+-- index-derived-collation resolution directly.
+
+create table idx_coll (id integer primary key, tag text);
+create unique index idx_tag_nc on idx_coll (tag collate nocase);
+insert into idx_coll values (1, 'Hello');
+
+insert into idx_coll values (2, 'HELLO') on conflict (tag) do update set tag = 'seen';
+select id, tag from idx_coll order by id;
+→ [{"id":1,"tag":"seen"}]
+
+drop table idx_coll;