@quereus/quereus 4.20.0 → 4.20.2

package/test/README.md

@@ -0,0 +1,173 @@
+# Quereus Tests
+
+Tests for the Quereus engine. Most behavior is exercised through SQL logic tests; lower-level unit tests live alongside in subdirectories.
+
+## Layout
+
+| Path | What lives there |
+|---|---|
+| `logic/*.sqllogic` | Primary regression suite — black-box SQL with expected results. Runner is `logic.spec.ts`. |
+| `plan/` | Optimizer plan-shape and golden-plan tests. See `plan/README.md`. |
+| `optimizer/` | Per-rule optimizer unit tests (pushdown, joins, aggregate strategy, statistics, etc.). |
+| `planner/` | Planner framework, cost model, predicate normalization, validation, stats. |
+| `runtime/` | Runtime emitter and execution unit tests (caches, scan emitter, temporal arithmetic, shadow DDL). |
+| `schema/` | Catalog and schema-differ tests. |
+| `vtab/` | Virtual-table contract tests (best-access plan, events, scan bounds, remote disconnect). |
+| `core/` | Core database/options API tests. |
+| `cross-platform/` | Browser and environment-compatibility checks. |
+| `util/` | Pure utility tests (hash, hrtime, plugin helpers, mutation-statement). |
+| `*.spec.ts` (top level) | Cross-cutting suites: parser, type system, fuzz, property, lifecycle, multi-statement, exports, capabilities, performance sentinels, etc. |
+
+## Running tests
+
+```bash
+yarn test            # default — memory vtab; this is what agents should run
+yarn test:store      # re-run logic suite against the LevelDB store module
+yarn test:full       # both (only for store-specific diagnosis or release prep)
+```
+
+Diagnostics for logic-test failures (flags are picked up by `logic.spec.ts`):
+
+```bash
+yarn test --show-plan                                  # concise query plan
+yarn test --plan-summary                               # one-line execution path
+yarn test --plan-full-detail                           # full plan as JSON
+yarn test --show-plan --expand-nodes "node1,node2"     # expand specific nodes
+yarn test --show-plan --max-plan-depth 3               # cap plan depth
+yarn test --show-program                               # instruction program
+yarn test --show-trace                                 # execution trace
+yarn test --trace-plan-stack                           # plan stack tracing in runtime
+yarn test --show-stack                                 # full stack traces
+yarn test --verbose                                    # verbose progress
+```
+
+`DEBUG=quereus:...` enables namespaced log output. To run a single ad-hoc spec without the workspace harness:
+
+```bash
+node --import ./packages/quereus/register.mjs node_modules/mocha/bin/mocha.js 'packages/quereus/test/**/*.spec.ts' --colors --bail
+```
+
+## Logic-test conventions
+
+- `→ [expected_json_results]` marks expected rows.
+- `-- error: <substring>` marks expected errors.
+- `-- requires-capability: <tokens>` declares database features the file needs; a backend that lacks one skips the whole file. See below.
+- Lowercase SQL keywords. Match the existing fixtures' style.
+- Inside a file, order scenarios **mundane → exotic** so the most general failure surfaces first.
+- File names carry a numeric prefix that places them in run order. The same mundane → exotic principle applies across files. Anchors:
+  - `01–17` — feature basics (parser, expressions, transactions, vtab, builtins, aggregates, joins, set ops, CTEs, temporal).
+  - `20–29` — feature edge cases (NULL, boundaries, self-join duplicates).
+  - `40–50` — semantics-heavy features (constraints, FKs, generated cols, RETURNING, declarative schema, assertions).
+  - `80–86` — optimizer / plan-shape concerns.
+  - `90–99`, `100+` — error paths, exotic edge cases, mutation kills.
+- Use a decimal sub-number to slot between adjacent files (`06.2.1-…` between `06.2-…` and `06.3-…`); don't renumber existing files.
+- Tests represent expected behavior when features are fully implemented. A failing test is a roadmap item, not a regression to silence.
+
+### `-- requires-capability:` directive
+
+`logic/*.sqllogic` is a **shared corpus** — other projects run the same files against their own storage
+engine. When a file's *subject* is a feature a backend deliberately does not implement, that file should
+skip there. Rather than have every consumer hand-maintain an O(corpus) list of file names, the file
+declares what it needs and each harness declares once what its backend has.
+
+**This section is the format spec, and the format is the cross-repo contract** — downstream harnesses
+reimplement the ~10-line parse against it. Quereus's own implementation is `test/logic-capabilities.ts`
+(not published — the npm package ships the corpus and this README, not the harness or compiled tests;
+see [Consuming the corpus from the npm package](#consuming-the-corpus-from-the-npm-package)).
+
+Grammar — the directive lives in the file's **leading comment block**, before the first line that is
+neither blank nor a `--` comment:
+
+```
+-- Row-validating DDL inside an open transaction.
+-- requires-capability: standalone-index-ddl
+
+create table ddl_tx_a (id integer primary key, v text);
+```
+
+- Canonical line shape after trimming: `-- requires-capability: <tokens>`. The directive name matches
+  case-insensitively; tokens are lowercased before lookup.
+- `<tokens>` is one or more tokens separated by whitespace and/or commas.
+- The directive may appear on several lines; the declared sets **union**. Duplicate tokens are fine.
+- **No trailing comment on a directive line** — the whole remainder is read as tokens, so
+  `-- requires-capability: x -- why` errors on `--` and `why`.
+- Granularity is **whole file**; there is no section-scoped form. If only part of a file needs a
+  capability and the rest is worth running elsewhere, **split the file** (`10.5.2-…` style decimal
+  sub-numbering) rather than inventing a scoped directive.
+
+Each of these is a **hard error** that fails that one file's test — never a silent skip, never a silent pass:
+
+- an unknown capability token,
+- a directive with no tokens,
+- a canonical directive appearing after the file's first SQL line,
+- a **near-miss spelling** — `-- require-capability:`, `-- requires_capability:`, `-- requires capability:`.
+  This last one matters: the runner `continue`s past every unrecognized `--` line, so without the guard a
+  typo'd directive would vanish and the file would run with nobody the wiser.
+
+**Vocabulary** (closed set):
+
+| Token | Meaning |
+|---|---|
+| `standalone-index-ddl` | Backend accepts `create index`, `create unique index`, and `drop index` as standalone statements. |
+
+Adding a member is a deliberate quereus change: one entry in `SQLLOGIC_CAPABILITIES`, one row in this
+table, and at least one file annotated with it. The set being closed is the point — every consumer of the
+corpus agrees on what the tokens mean, so a downstream backend cannot mint private tokens. Group tokens
+by "a feature a backend would realistically choose to omit wholesale"; do **not** mint a capability per test.
+
+**What this is NOT.** Two adjacent concepts exist; keep them apart.
+
+- `ModuleCapabilities` (`src/vtab/capabilities.ts`) is a *runtime* interface a virtual-table module
+  advertises to the engine (`isolation`, `savepoints`, `secondaryIndexes`, `ddlTransactionality`, …). This
+  directive is a *test-harness* concept about whole SQL statements a backend accepts. One is not derived
+  from the other: `secondaryIndexes: true` means "supports secondary indexes", which a backend can satisfy
+  through declared schema or covering materialized views while still having no standalone `create index`
+  statement. Different question, different answer — hence the distinct type name `SqllogicCapability`.
+- `MEMORY_ONLY_FILES` (`logic.spec.ts`) is quereus's own store-mode exclusion list and stays as it is.
+  Split rule: capability-shaped divergence → file directive; memory-engine quirk, cost-model choice,
+  harness-config assertion, white-box internals, or known-bug divergence → that set.
+
+Both of quereus's backends ship standalone index DDL, so the mechanism produces **zero local skips** today.
+That is expected — the payoff is downstream. A file skipping locally means the capability sets or the
+directive are wrong.
+
+### Consuming the corpus from the npm package
+
+`@quereus/quereus` ships `test/logic/*.sqllogic` and `test/README.md` in its tarball, so a consumer
+runs the corpus that matches the engine version it installed. The `exports` map exposes `./package.json` for exactly this: resolve it, take its directory,
+and read `test/logic` from there.
+
+```ts
+import { createRequire } from 'node:module';
+import { dirname, join } from 'node:path';
+const corpusDir = join(dirname(createRequire(import.meta.url).resolve('@quereus/quereus/package.json')), 'test', 'logic');
+```
+
+No other path under `test/` is exported or guaranteed to ship. A pattern export such as
+`./test/logic/*` was rejected because it resolves single files but cannot be listed.
+
+## Test philosophy
+
+Tests are the contract. When a feature is incomplete, write the test the way the feature *should* behave and let it fail — that documents the gap. Don't add `-- skip` markers, don't relax expected results to match observed output, don't comment out assertions.
+
+## Historical: SQLite test cross-check
+
+Between 2026-04 and 2026-05, the suite was systematically expanded by cross-checking SQLite's own test corpus (the TCL `test/*.test` files in the upstream `sqlite/sqlite` repo, with the sqllogictest corpus as a secondary reference) against `test/logic/`. The shared workspace doc was `docs/sqlite-test-crosscheck.md`; the workflow was `docs/sqlite-test-crosscheck-process.md`. Twelve `5-sqlite-xref-*` implement tickets carried out the work, one per category (SELECT/output, WHERE/BETWEEN, joins, indexes, subqueries/CTE, aggregates/windows, expressions/types, scalar functions, temporal/JSON functions, DML, DDL/constraints, transactions/bind/errors).
+
+Key rules that shaped the resulting fixtures:
+
+- **Applicability filter.** SQLite tests covering rowids, btree/pager/wal internals, vacuum/backup/attach, triggers, type-affinity coercion, fault injection, and file-page pragmas are `n/a` to Quereus by design — see the out-of-scope block in the cross-check doc and `docs/architecture.md` § Design Differences from SQLite. They were dead-marked, not translated.
+- **Distill, don't transliterate.** SQLite TCL tests carry a lot of plumbing (procs, do_test wrappers, db open/close, file deletion). The SQL kept in our fixtures is the minimum that exercises the scenario.
+- **Adapt to Quereus semantics.** NOT NULL by default, no rowids, explicit type conversions, key-based addressing — expected results were rewritten where SQLite's defaults differ. Where Quereus deliberately rejects an SQLite input, the fixture asserts the rejection via `-- error: <substring>`.
+- **Failing tests were the deliverable.** The cross-check passes wrote fixtures that document gaps; making them pass is a separate downstream pass. Look for fixtures whose internal scenarios fail to find the still-open work.
+- **Status calibration.** Each row in the index landed at `covered`, `partial`, `gap`, or `n/a`. `partial` and `gap` rows produced new fixtures, logged in the doc's Gaps Log with their final filenames.
+
+The full state, status legend, per-category index, and per-fixture Gaps Log live in `docs/sqlite-test-crosscheck.md` — consult it when adding more SQLite-derived coverage so existing classifications aren't redone, and when triaging which failing fixture covers which SQLite scenario.
+
+## Adding new tests
+
+1. Pick the right kind: `.sqllogic` first; property test (`property.spec.ts`) only when an invariant naturally generalizes; unit test only when SQL-level coverage can't reach the surface.
+   - Fixing a clause the parser accepted but no builder ever read? The behaviour goes in a `.sqllogic`, and a row also goes in `clause-canary.spec.ts` — one query per clause whose answer must differ from the same query with the clause removed. That suite guards the *class* (a silently-dropped clause), not any one clause's correctness.
+2. For `.sqllogic`, name the file by feature/scenario (`between-with-nulls.sqllogic`), prefix it numerically per the run-order anchors above, and order scenarios inside the file mundane → exotic.
+3. Run `yarn test` to confirm the test exercises what you expect. If it's documenting a gap, leave it failing — don't paper over it.
+4. Update the relevant docs (this README, the cross-check doc, or the topic doc in `docs/`) when adding a whole new category.

package/test/logic/01-basic.sqllogic

@@ -0,0 +1,39 @@
+-- Test the basics of create and select
+
+CREATE TABLE t (a TEXT, b INTEGER);
+INSERT INTO t VALUES ('a', 10);
+
+select a, b from t;
+→ [{"a": "a", "b": 10}]
+
+DROP TABLE t;
+
+-- Test CREATE TABLE IF NOT EXISTS
+
+CREATE TABLE IF NOT EXISTS t1 (id INTEGER PRIMARY KEY, name TEXT);
+
+-- Insert a row to verify the table was created
+INSERT INTO t1 VALUES (1, 'Alice');
+
+SELECT * FROM t1;
+→ [{"id": 1, "name": "Alice"}]
+
+-- Second CREATE TABLE IF NOT EXISTS should be a no-op (not error)
+CREATE TABLE IF NOT EXISTS t1 (id INTEGER PRIMARY KEY, name TEXT);
+
+-- Verify original data is still there (not reset)
+SELECT * FROM t1;
+→ [{"id": 1, "name": "Alice"}]
+
+-- Insert another row to confirm table still works
+INSERT INTO t1 VALUES (2, 'Bob');
+
+SELECT * FROM t1 ORDER BY id;
+→ [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]
+
+DROP TABLE t1;
+
+-- Test that CREATE TABLE without IF NOT EXISTS errors when table exists
+CREATE TABLE t2 (x INTEGER);
+CREATE TABLE t2 (x INTEGER);
+-- error: already exists

package/test/logic/01.1-select-projection-extras.sqllogic

@@ -0,0 +1,130 @@
+-- adapted from SQLite test/select1.test, test/selectD.test, test/e_select.test
+-- SELECT projection corner cases: duplicate wildcard expansion,
+-- qualified column refs across self-join, parenthesized FROM clauses.
+
+create table t1 (a integer primary key, b text);
+insert into t1 values (1, 'one');
+
+-- Single-row sanity check before exercising projection
+select a, b from t1;
+→ [{"a":1,"b":"one"}]
+
+-- Duplicate wildcard in projection — column names disambiguated
+select *, * from t1;
+→ [{"a":1,"b":"one","a:1":1,"b:1":"one"}]
+
+-- Wildcard plus literal expression
+select *, 'lit' as marker from t1;
+→ [{"a":1,"b":"one","marker":"lit"}]
+
+-- =============================================================================
+-- Star position: a `*` in the select list is expanded in place, not hoisted to
+-- the front of the output. Regression for
+-- bug-star-in-select-list-ignores-its-position.
+-- =============================================================================
+
+-- A named column before the star: the star's own `a` collides with the named
+-- one and is disambiguated (`a:1`), the star's `b` is not.
+select a, * from t1;
+→ [{"a":1,"a:1":1,"b":"one"}]
+
+-- A named column aliased onto the star's own column name: order decides which
+-- occurrence keeps the bare name and which gets the `:1` suffix, so this is
+-- the case that actually distinguishes written order from star-first — the
+-- two occurrences carry different values (`b`'s value vs `a`'s value).
+select b as a, * from t1;
+→ [{"a":"one","a:1":1,"b":"one"}]
+
+-- A star between two named columns.
+select a, *, b from t1;
+→ [{"a":1,"a:1":1,"b":"one","b:1":"one"}]
+
+-- A star after a computed column.
+select upper(b) u, * from t1;
+→ [{"u":"ONE","a":1,"b":"one"}]
+
+-- Qualified column refs over a self-join (cross join)
+insert into t1 values (2, 'two');
+
+select A.a as la, B.a as ra from t1 as A cross join t1 as B order by la, ra;
+→ [{"la":1,"ra":1},{"la":1,"ra":2},{"la":2,"ra":1},{"la":2,"ra":2}]
+
+select A.*, B.* from t1 as A cross join t1 as B order by A.a, B.a;
+→ [{"a":1,"b":"one","a:1":1,"b:1":"one"},{"a":1,"b":"one","a:1":2,"b:1":"two"},{"a":2,"b":"two","a:1":1,"b:1":"one"},{"a":2,"b":"two","a:1":2,"b:1":"two"}]
+
+-- A qualified star after a named column, over the same self-join.
+select A.a as la, B.* from t1 as A cross join t1 as B order by la, B.a;
+→ [{"la":1,"a":1,"b":"one"},{"la":1,"a":2,"b":"two"},{"la":2,"a":1,"b":"one"},{"la":2,"a":2,"b":"two"}]
+
+drop table t1;
+
+-- =============================================================================
+-- Parenthesized FROM expressions: (a join b) join c
+-- =============================================================================
+
+create table p1 (id integer primary key, val text);
+create table p2 (id integer primary key, p1_id integer);
+create table p3 (id integer primary key, p2_id integer);
+insert into p1 values (1, 'A'), (2, 'B');
+insert into p2 values (10, 1), (20, 2);
+insert into p3 values (100, 10), (200, 20);
+
+-- Inner join wrapped in parentheses, then joined to a third table
+select p1.id as l, p2.id as m, p3.id as r
+from (p1 join p2 on p1.id = p2.p1_id) join p3 on p2.id = p3.p2_id
+order by l;
+-- error: Expected table name
+
+-- Left side scalar table joined to a parenthesized inner-join subexpression
+select p1.id as l, p2.id as m, p3.id as r
+from p1 left join (p2 join p3 on p2.id = p3.p2_id) on p1.id = p2.p1_id
+order by l;
+-- error: Expected table name
+
+drop table p3;
+drop table p2;
+drop table p1;
+
+-- =============================================================================
+-- UNION column-name derivation: names come from the left SELECT
+-- =============================================================================
+
+create table u1 (f1 integer);
+create table u2 (r2 real);
+insert into u1 values (11);
+insert into u2 values (1.5);
+
+-- Result column is named after the left SELECT's expression
+select f1 from u1
+union
+select r2 from u2
+order by f1;
+→ [{"f1":1.5},{"f1":11}]
+
+-- ORDER BY can reference the left-side name even though right side has different name
+select f1 as label from u1
+union all
+select r2 from u2
+order by label;
+→ [{"label":1.5},{"label":11}]
+
+drop table u2;
+drop table u1;
+
+-- =============================================================================
+-- Bare (no-AS) aliases followed by more list items — regression coverage for
+-- a parser bug where a bare alias was rejected whenever a comma followed it
+-- =============================================================================
+
+create table b1 (k integer primary key, j integer);
+insert into b1 values (1, 10), (2, 20);
+
+-- Bare column aliases, none of which is the last item in the list
+select k kk, j jj from b1 order by kk;
+→ [{"kk":1,"jj":10},{"kk":2,"jj":20}]
+
+-- Bare alias immediately before a window function column
+select k kk, row_number() over (order by k) rn from b1 order by kk;
+→ [{"kk":1,"rn":1},{"kk":2,"rn":2}]
+
+drop table b1;

package/test/logic/01.2-strings.sqllogic

@@ -0,0 +1,43 @@
+-- various string literals
+
+-- Basic multi-line single-quoted string
+SELECT 'hello
+world' as multiline;
+→ [{"multiline":"hello\nworld"}]
+
+-- Multi-line string with explicit content
+SELECT 'line one
+line two
+line three' as text;
+→ [{"text":"line one\nline two\nline three"}]
+
+-- Multi-line string in WHERE clause
+CREATE TABLE test_multiline (id INTEGER PRIMARY KEY, content TEXT);
+INSERT INTO test_multiline VALUES (1, 'hello
+world');
+SELECT * FROM test_multiline WHERE content = 'hello
+world';
+→ [{"id":1,"content":"hello\nworld"}]
+
+-- Multi-line string with special characters
+SELECT 'first line
+second line with spaces
+third line' as formatted;
+→ [{"formatted":"first line\nsecond line with spaces\nthird line"}]
+
+-- String concatenation with multi-line strings
+SELECT 'multi
+line' || ' ' || 'another
+multi
+line' as concatenated;
+→ [{"concatenated":"multi\nline another\nmulti\nline"}]
+
+-- SQL standard escaped quotes ('' represents a single quote)
+SELECT 'hello''world' as escaped;
+→ [{"escaped":"hello'world"}]
+
+-- Escaped quotes in multi-line string (inch marks example)
+SELECT '60'''' total: 36'''' center' as measurement;
+→ [{"measurement":"60'' total: 36'' center"}]
+
+DROP TABLE test_multiline;

package/test/logic/01.5-insert-select.sqllogic

@@ -0,0 +1,237 @@
+-- adapted from SQLite test/insert2.test, test/insert4.test, test/insert5.test
+-- INSERT ... SELECT variants beyond the simple form covered in 01-basic and 13-cte.
+-- Quereus has no rowids and NOT NULL by default; subagent reports flagged
+-- column-reordering, compound select, JOIN, GROUP BY, DISTINCT, LIMIT,
+-- self-reference and view-mediated INSERT...SELECT as uncovered scenarios.
+
+-- ===================================
+-- 1. INSERT ... SELECT with column reordering / partial mapping
+-- ===================================
+
+create table src_basic (a integer primary key, b text null, c integer null);
+create table dst_basic (a integer primary key, b text null, c integer null);
+
+insert into src_basic values (1, 'x', 10), (2, 'y', 20);
+
+-- target column list reorders columns relative to SELECT projection
+insert into dst_basic (c, a) select c, a from src_basic;
+
+select a, b, c from dst_basic order by a;
+→ [{"a":1,"b":null,"c":10},{"a":2,"b":null,"c":20}]
+
+drop table dst_basic;
+drop table src_basic;
+
+-- ===================================
+-- 2. INSERT ... SELECT with GROUP BY aggregation
+-- ===================================
+
+create table events (id integer primary key, grp text, n integer);
+insert into events values (1, 'A', 10), (2, 'A', 5), (3, 'B', 20);
+
+create table summary (grp text primary key, total integer);
+insert into summary (grp, total) select grp, sum(n) from events group by grp;
+
+select grp, total from summary order by grp;
+→ [{"grp":"A","total":15},{"grp":"B","total":20}]
+
+drop table summary;
+drop table events;
+
+-- ===================================
+-- 3. INSERT ... SELECT with compound (UNION ALL, EXCEPT)
+-- ===================================
+
+create table s1 (id integer primary key, val text);
+create table s2 (id integer primary key, val text);
+insert into s1 values (1, 'apple'), (2, 'banana');
+insert into s2 values (2, 'banana'), (3, 'cherry');
+
+create table u_dst (id integer primary key, val text);
+
+insert into u_dst (id, val) select id, val from s1 union all select id + 100, val from s2;
+select id, val from u_dst order by id;
+→ [{"id":1,"val":"apple"},{"id":2,"val":"banana"},{"id":102,"val":"banana"},{"id":103,"val":"cherry"}]
+
+drop table u_dst;
+
+create table e_dst (id integer primary key, val text);
+insert into e_dst (id, val) select id, val from s1 except select id, val from s2;
+select id, val from e_dst order by id;
+→ [{"id":1,"val":"apple"}]
+
+drop table e_dst;
+drop table s2;
+drop table s1;
+
+-- ===================================
+-- 4. INSERT ... SELECT from JOIN (LEFT JOIN with NULL padding)
+-- ===================================
+
+create table l (id integer primary key, val text);
+create table r (id integer primary key, left_id integer, info text);
+insert into l values (1, 'a'), (2, 'b');
+insert into r values (10, 1, 'x');
+
+create table joined (id integer primary key, val text, info text null);
+
+insert into joined (id, val, info)
+   select l.id, l.val, r.info from l left join r on l.id = r.left_id;
+
+select id, val, info from joined order by id;
+→ [{"id":1,"val":"a","info":"x"},{"id":2,"val":"b","info":null}]
+
+drop table joined;
+drop table r;
+drop table l;
+
+-- ===================================
+-- 5. INSERT ... SELECT with DISTINCT (suppress duplicates)
+-- ===================================
+
+create table dup_src (id integer primary key, x integer, y integer);
+insert into dup_src values (1, 1, 10), (2, 1, 10), (3, 2, 20);
+
+create table dup_dst (x integer, y integer, primary key (x, y));
+insert into dup_dst select distinct x, y from dup_src;
+
+select x, y from dup_dst order by x, y;
+→ [{"x":1,"y":10},{"x":2,"y":20}]
+
+drop table dup_dst;
+drop table dup_src;
+
+-- ===================================
+-- 6. INSERT ... SELECT with LIMIT
+-- ===================================
+
+create table lim_src (id integer primary key, val integer);
+create table lim_dst (id integer primary key, val integer);
+
+insert into lim_src values (1, 100), (2, 200), (3, 300);
+insert into lim_dst select id, val from lim_src order by id limit 2;
+
+select id, val from lim_dst order by id;
+→ [{"id":1,"val":100},{"id":2,"val":200}]
+
+drop table lim_dst;
+drop table lim_src;
+
+-- ===================================
+-- 7. INSERT ... SELECT self-referential (insert from same table)
+-- ===================================
+
+create table doubler (id integer primary key, val integer);
+insert into doubler values (1, 10), (2, 20);
+
+insert into doubler (id, val) select id + 100, val * 2 from doubler;
+
+select id, val from doubler order by id;
+→ [{"id":1,"val":10},{"id":2,"val":20},{"id":101,"val":20},{"id":102,"val":40}]
+
+drop table doubler;
+
+-- ===================================
+-- 7b. INSERT ... SELECT self-referential, mid-transaction (after prior writes)
+-- ===================================
+-- Same shape as section 7, but wrapped in BEGIN ... COMMIT with a seeding
+-- INSERT VALUES so the connection's pendingTransactionLayer is non-null when
+-- the self-ref INSERT runs. This exercises the eager savepoint-snapshot
+-- branch in MemoryTableConnection.createSavepoint: without the readLayer
+-- swap, the SELECT iterator and the INSERT mutate the same BTree and the
+-- new rows feed back into the SELECT (halloween), causing val*2 to keep
+-- doubling row by row until Number.isSafeInteger rejects it.
+
+create table doubler_tx (id integer primary key, val integer);
+
+begin;
+insert into doubler_tx values (1, 10), (2, 20);
+insert into doubler_tx (id, val) select id + 100, val * 2 from doubler_tx;
+commit;
+
+select id, val from doubler_tx order by id;
+→ [{"id":1,"val":10},{"id":2,"val":20},{"id":101,"val":20},{"id":102,"val":40}]
+
+drop table doubler_tx;
+
+-- ===================================
+-- 8. INSERT ... SELECT through a view of the target table
+-- ===================================
+
+create table v_target (id integer primary key, name text);
+insert into v_target values (1, 'Alice'), (2, 'Bob');
+
+create view v_target_v as select id, name from v_target where id > 0;
+
+insert into v_target (id, name) select id + 10, name || '_v' from v_target_v;
+
+select id, name from v_target order by id;
+→ [{"id":1,"name":"Alice"},{"id":2,"name":"Bob"},{"id":11,"name":"Alice_v"},{"id":12,"name":"Bob_v"}]
+
+drop view v_target_v;
+drop table v_target;
+
+-- ===================================
+-- 9. INSERT ... SELECT with CHECK constraint enforcement on target
+-- ===================================
+
+create table chk_src (a integer, b integer);
+create table chk_dst (a integer, b integer check (b > a));
+insert into chk_src values (10, 20), (30, 25);
+
+-- only the row that satisfies CHECK should be admitted; the other should error
+insert into chk_dst select a, b from chk_src where b > a;
+select a, b from chk_dst order by a;
+→ [{"a":10,"b":20}]
+
+-- attempting to insert the violating row directly errors
+insert into chk_dst select a, b from chk_src where a = 30;
+-- error: CHECK constraint failed
+
+drop table chk_dst;
+drop table chk_src;
+
+-- ===================================
+-- 10. INSERT ... SELECT with correlated subquery in WHERE referencing target
+-- ===================================
+
+create table self_ref (id integer primary key, val integer);
+insert into self_ref values (1, 10), (2, 20), (3, 30);
+
+insert into self_ref (id, val)
+   select id + 100, 99 from self_ref where id in (select id from self_ref where val > 15);
+
+select id, val from self_ref order by id;
+→ [{"id":1,"val":10},{"id":2,"val":20},{"id":3,"val":30},{"id":102,"val":99},{"id":103,"val":99}]
+
+drop table self_ref;
+
+-- ===================================
+-- 11. Duplicate column in the INSERT column list is rejected (no silent
+--     last-wins / confusing shape). PostgreSQL rejects this as
+--     "column \"a\" specified more than once". See ticket
+--     insert-family-duplicate-column-targets-silent-last-wins.
+-- ===================================
+
+create table dup_cols (a integer primary key, b integer null);
+
+insert into dup_cols (a, a) values (1, 2);
+-- error: specified more than once
+
+-- case-insensitive duplicate is also rejected.
+insert into dup_cols (a, b, A) values (1, 2, 3);
+-- error: specified more than once
+
+-- the rejected inserts made no change.
+select a, b from dup_cols order by a;
+→ []
+
+-- false-positive guard: the check keys on exact-name collision, so a legitimate
+-- distinct-column list still works — including columns that merely share a prefix.
+create table prefix_cols (ab integer primary key, abc integer null);
+insert into prefix_cols (ab, abc) values (1, 2);
+select ab, abc from prefix_cols order by ab;
+→ [{"ab":1,"abc":2}]
+drop table prefix_cols;
+
+drop table dup_cols;