[finding] sql-driver-aggregation-conformance.test.ts hard-codes better-sqlite3, so the aggregate-vocabulary standard never runs on Postgres — its pagination sibling already uses the live-dialect cells

[os-steve]

Observed while taking the #11152 readings. Filed unassigned as an observation — it is a reach question about an existing harness, not a defect with a settled fix.

What was observed

packages/drivers/driver-sql/src/sql-driver-aggregation-conformance.test.ts constructs its driver with a literal:

driver = new SqlDriver({
 client: 'better-sqlite3',
 connection: { filename: ':memory:' },
 useNullAsDefault: true,
});

Its sibling sql-driver-pagination-conformance.test.ts — the same family, the same package — goes through live-dialect-matrix.testkit.ts and so runs on Postgres and MySQL whenever OS_TEST_POSTGRES_URL / OS_TEST_MYSQL_URL are provisioned.

So the shared aggregate-vocabulary standard, which exists so that two faces of one platform cannot answer one aggregation two ways, is measured on exactly one dialect of the driver that speaks three.

Why it matters, concretely

This is not hypothetical reach. Measured on a live PostgreSQL 16.13 (recorded on #11455): sum, avg, min and max over a boolean column all throw 42883 on Postgres while answering normally on SQLite. The aggregation conformance suite is green throughout, on main, on every PR — because no cell of it has ever executed against Postgres.

That is the same shape the testkit's own head note was written about, quoted from it:

a hard-coded client is invisible. sql-driver-temporal-conformance.test.ts carried four of them while its own head note claimed it ran "against real Postgres and MySQL too" — declared != enforced, and the ADR's Postgres at minimum never executed for the matrix at all.

ADR-0053 D-A3 states the matrix is driver {SQLite, Postgres at minimum}.

What it would take, and the reason this is filed rather than done

Converting the suite is more than swapping the constructor: the fixture is seeded per cell, the count/count_distinct answers come back as strings on pg (measured: count(flag) => [{"n":"6"}], types=["string"]) where SQLite hands back numbers, so actualFor's Number(r.n) coercion and the readback assertions need a per-dialect reading rather than a mechanical port. And on today's main the converted suite would be red on Postgres for any boolean case, and red for the reason #11455 records rather than for a reason this conversion introduces.

So the order matters: #11455 (or whatever settles the boolean-aggregand contract) first, this conversion after. Doing it in the other order lands a red.

Related: #11152, #11455, #11249, #11065.

[os-zhuang]

Triage (first-touch grading): graded — finding → pm:blocked, domain:engine, type Task.

Blocked-by: #11635

Rationale: the card's own ordering claim is confirmed by the standing record — the boolean-aggregand contract on the PG face is now carried by #11635 (the ruled false/true + arithmetic answers are unproducible on PG until the lowering cast lands; the same shared-damage direction was already adjudicated when #11152 was re-pointed at it). Converting this suite to the live-dialect matrix before #11635 lands a red on main for a reason the conversion did not introduce.

Unlock-action, pre-written: when #11635 closes, re-verify on the merged ref (the cast fix may have converted this suite as part of its own proof — absorb-close if so), then requeue with the deliverable: route sql-driver-aggregation-conformance.test.ts through live-dialect-matrix.testkit.ts per ADR-0053 D-A3 (Postgres at minimum), with the per-dialect readback readings the card names (pg returns count as strings — Number(r.n) coercion needs a per-dialect face, not a mechanical port).

---

Generated by Claude Code