Three correctness fixes, TypeScript 7, and plpgsql bodies for #91

[productdevbook]

Nine commits. Three defects in the shipped library, the toolchain moved forward two majors, and the half of #91 that was still missing.

Fixes

select("posts.id") emitted SQL Postgres rejects. It quoted the whole string as one identifier — SELECT "posts.id" — naming a column no table has. Every join that named its columns was broken at run time. columns, distinctOn, groupBy and orderBy now route through parseColumnRef, and the type admits table.column for the tables in scope.

How it survived: bench/src/scenarios.ts used that form and pinned the broken output in a snapshot, but tsconfig.json included only src and test, so nothing typechecked the benchmark. It is inside include now, and sumak's own types reject the form — nobody was looking.

The emitted SQL depended on parameter values. deduplicatePredicates fingerprinted a parameter by its value:

id = 1 AND id = 1  ->  WHERE ("id" = $1)
id = 1 AND id = 2  ->  WHERE (("id" = $1) AND ("id" = $2))

The IN(...) fast path was worse — it fingerprinted an all-parameter list by arity alone, so id IN (1,2) AND id IN (3,4) became WHERE ("id" IN ($1, $2)). Wrong rows, not a cosmetic difference.

A parameter now fingerprints as its occurrence. Literals still dedupe, because a literal is written into the text and is part of the shape. The trade is deliberate: name = $1 AND name = $2 where name = $1 used to be when the values happen to match — one redundant parameter, discarded by any planner — and in exchange one call site emits one SQL text, which is what lets the database reuse a prepared statement's plan.

toCompiled() skipped parameter conversion. It fills placeholders without printing, so the printer's conversion never ran for those values, and a bigint reached pg raw — which the driver rejects. Printer now exposes coerceParam and the compiled path applies it.

Feature — #91

#91 asks for database infrastructure to live in the codebase as typed code. RLS landed in #172/#179 and typed CREATE FUNCTION / CREATE TRIGGER in #191, but a function could only have an expression body — and a function with an expression body is a SELECT with extra steps.

createFunction("compute_total")
  .args({ price: arg("integer"), quantity: arg("integer") })
  .returns("integer")
  .plpgsql((b, { price, quantity }) => {
    b.if(typedLte(quantity, val(0)), (t) => t.raise("exception", "quantity must be positive"))
    b.return(typedMul(price, quantity))
  })

DECLARE, assignment, IF/ELSIF/ELSE, WHILE, FOR over a range or a query, bare LOOP, EXIT/CONTINUE with WHEN, RAISE with USING, PERFORM, embedded statements, nested blocks, RETURN / RETURN NEXT / RETURN QUERY. triggerScope names NEW, OLD, TG_OP, TG_TABLE_NAME, TG_TABLE_SCHEMA.

Every test runs the function in pglite rather than comparing strings, because a plpgsql body is a string literal to the outer parser — a missing semicolon after END IF creates the function happily and fails when it is called. That caught two things:

• plpgsql folds unquoted identifiers to lower case, so its variable is new and a quoted "NEW" resolves to nothing. triggerScope emits lower case for the variable half.
• A placeholder inside $$ … $$ names one of the function's own arguments, so a parameter in an embedded statement is refused rather than silently bound to the wrong thing.

Toolchain

TypeScript 7 is the native compiler, so @typescript/native-preview is dropped and typecheck is plain tsc --noEmit — 0.6s for the repository. Also drizzle-orm 1.0.0-rc.4, kysely 0.29.5, CASL 7, better-sqlite3 13, oxlint/oxfmt/vitest/pglite. Two majors broke us: CASL returns readonly Rule[] from rulesFor, and drizzle dropped schema from DrizzlePgConfig and changed what it emits.

Documentation

docs/ is removed at the maintainer's request; the README link and the copy.ts reference went with it rather than dangling.

The benchmark is re-measured across all 48 scenarios. The README claimed "seven canonical shapes, wins six of the seven, 9×–39× vs drizzle" — the harness has had 48 for a while, sumak wins 32, and drizzle 1.0 is much faster than the version that claim was measured against, so the real range is 2.2×–14.7×. The sixteen kysely wins are now listed and grouped by cause. The per-compile table said the slowest scenario was ~28µs; it is insert-many-100 at 90µs.

README also gains a Functions and Triggers section, which it never had.

Verification

pnpm test (lint + typecheck + 3342 tests) green, pnpm build clean, npm pack 304 files.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HAwiBVhLmNhWjC9Ro6UMpb

[productdevbook]

Two more commits: the architecture the mvp/ sketch was testing now lives in src/, and mvp/ is deleted.

The compiled path is the one a request takes

A query's shape is fixed where it is typed; only the values change per request. toCompiled() already compiled once, but filling was slower than it needed to be, so the split was not worth reaching for. Filling is now specialised by arity — an array literal for the arities that cover almost every query:

path	per call
.toSQL() — rebuilds and recompiles	~3,200ns
.toCompiled() — no parameters	~6.7ns
.toCompiled() — one parameter	~5.8ns
.toCompiled() — two parameters	~12.1ns

It was 84ns before this, so the architecture was already there; what was missing was it being worth using. test/builder/compiled-shape.test.ts pins the properties rather than the timing: one SQL string whatever the values, a fresh parameter array per call, and the pipeline never consulted again.

Measured on the way: Array.from({ length: n }) is 20× slower than the alternatives — 479.8ns against 23.0ns for new Array(n) and 35.5ns building by push. Earlier in this branch I replaced new Array(len) in the printer's IN(...) path with it to silence a lint warning, without measuring. That is undone; the printer builds by push now, which is both fast and unambiguous.

A write accepts an expression

The audit trigger #91 opens with could not be written. insertInto("audit").values({ action: TG_OP, product: NEW.name }) turned both into bound parameters, and inside $$ … $$ a placeholder names one of the function's own arguments. values() and set() now pass a branded expression through as itself and parameterise everything else; Insertable / Updateable widen to match, because the runtime half alone would leave the type rejecting what the builder accepts — the same shape of bug as select("posts.id").

forEach also declares its loop variable as a record. plpgsql refuses FOR r IN <query> otherwise, and the error arrives when the function runs.

Both surfaced from pushing the new builder's coverage from 73% to 96% by executing the untested paths — FOR over a query, CONTINUE WHEN, embedded statements, nested blocks, RETURN NEXT, RETURN QUERY, a declaration inside a branch.

Tests

The type tests for Insertable / Updateable asserted the narrow shape and now assert the contract by assignment: required stays required, a column keeps its type, an expression is accepted where its value goes.

I also audited the suite for dead weight and did not find much worth cutting. The signals were false positives — 62 "no assertion" tests are mostly "runs against a live engine without throwing", 101 "duplicate names" are the same assertion across different dialects, 23 "identical bodies" likewise. expectTypeOf assertions were checked by mutation and do bite. The one real filler was in tests I wrote myself, and it is gone.

pnpm test green: 3329 tests, lint clean, tsc --noEmit clean, build clean.

[productdevbook]

Two more commits, and the test analysis you asked for — with the negative result stated rather than hidden.

A compiled query can run itself

The compiled path was the fast one and the inconvenient one at the same time: it handed back { sql, params } and left the caller to drive the connection, so the split it exists to express was not what anybody reached for.

const olderThan = db.selectFrom("users").select("name")
  .where(({ age }) => age.gt(placeholder("age")))
  .toCompiled<{ age: number }>()

await olderThan.many({ age: 40 })   // typed rows
await olderThan.one({ age: 40 })
await olderThan.first({ age: 40 })
await renameUser.run({ id: 1, newName: "ada" })

Rows are typed — toCompiled() carries the builder's row type through. The result context is derived once, from the AST that was already built; many() on the uncompiled builder derives it per call and builds the AST twice, once for the context and once inside toSQL().

The test analysis

Two methods, run properly.

Per-file coverage sweep. Every one of the 258 test files measured on its own, then compared against the union of the others. 77 files cover no unique statement. That is not a deletion list, and I am not treating it as one: coverage measures which lines ran, not which behaviours are pinned. test/dialect/mysql.test.ts covers nothing unique because other tests exercise the same printer lines, but it pins dialect.name, which assertFeature gates every dialect check on. Deleting on this signal would remove protection and leave coverage flat — exactly the wrong trade.

Reading what coverage wanted to delete. Twelve files pair a "builder shape" block with an emission block. Dropping the shape blocks costs 0 statements in two of them (custom-types, row-level-security) and 1–9 in the other ten. But reading the two "free" ones showed coverage was necessary and not sufficient: half of those tests assert aliasing and idempotence —

builder is immutable — branching returns independent nodes
build() returns a fresh array (mutating it doesn't affect the builder)
defensively copies the names array
.to() replaces a previous .to() call
CASCADE → RESTRICT flips (last call wins)

— which the SQL cannot show and coverage cannot distinguish, because the same statements run either way.

So: 32 tests removed, all of the seeds an empty X / .x(v) sets the slot family, with coverage verified identical. Everything else stays, and the earlier signals I reported — 62 "no assertion", 101 "duplicate name", 23 "identical body" — were all false positives on inspection.

The honest summary is that this suite does not have meaningful dead weight, and the tooling that claims otherwise is measuring the wrong thing.

pnpm test green: 3303 tests, lint clean, types clean, build clean.