Drizzle acceptance: 50-line program against real Postgres via @perryts/postgres

[proggeramlug]

Scope

Closes the first + second bullets of #420's acceptance list:

• Schema definition + insert/select/update/delete + a relation join in a 50-line program compiles via `perry compile`, produces a single-file native binary, runs against a real Postgres, and matches the same program under `node --experimental-strip-types`.
• One of: pg, mysql2, sqlite drivers verified end-to-end. Others as follow-up.

Driver choice: @perryts/postgres (pure-TS)

Use `@perryts/postgres` (pure-TS Postgres wire-protocol driver, lives at `PerryTS/postgres` repo) instead of the native `pg` (perry-ext-pg). Reason: perry's `compilePackages` story works best when the whole dep tree is pure TS — drizzle + driver + perry-stdlib net.Socket. perry-ext-pg uses sqlx under the hood and bypasses perry's net pipeline; @perryts/postgres exercises the full `import 'net' → net.Socket → wire protocol` path that perry already supports end-to-end.

What's done as of v0.5.585

• `import { sql } from 'drizzle-orm'` works
• `import { pgTable, serial, text, integer } from 'drizzle-orm/pg-core'` works
• 6-line schema definition compiles + runs (v0.5.576 duplicate-symbol fix on `__perry_wrap_perry_unknown_func`)

What's left

1. Wire `@perryts/postgres` as drizzle's pg driver in a new `test-drizzle-min.ts`.
2. 50-line program: schema (`pgTable users` + `pgTable posts` with FK), insert + select + update + delete + relation join via `leftJoin`.
3. Run against a real Postgres on `127.0.0.1:5432` (CI fixture or locally-run `docker run -p 5432:5432 postgres`).
4. Diff binary output against `node --experimental-strip-types test-drizzle-min.ts`.
5. Land any compile-time + runtime fixes uncovered along the way under this issue.

Likely shake-out areas

• Type-level query DSL (heavy generics) — perry uses SWC for parsing so should be fine, but worth a real test.
• Drizzle's `pg-core` hands off to the underlying client. Verify the `sql` template literal lowers correctly when used through drizzle's internals.
• Connection pool semantics (drizzle uses persistent connections) interact with @perryts/postgres's own connection-state machine.

Blocked on

If hono's #485 (class-field inheritance across compilePackages) reproduces in drizzle's prototype-mutation patterns, fix that first. Drizzle is more value-oriented than class-oriented though, so probably doesn't hit this — but verify.

Note: perry-ext-pg can stay around for users who want sqlx perf without touching their app code; the well-known table routes `import 'pg'` to it. Drizzle just gets a different default-stack for its end-to-end demo.

[proggeramlug]

Acceptance status as of v0.5.684

50-line program (schema with pgTable users + pgTable posts + FK, insert/select/update/delete + leftJoin) authored against @perryts/postgres 0.2.1 + drizzle-orm 0.45.2 via the pg-proxy adapter. Full source matches Bun byte-for-byte.

Compile + link: clean — 6.0 MB binary on first try.

Runtime: TCP connect works after one driver patch, but query execution hits two perry-side gaps.

Blocked on three things

1. Cross-module instanceof returns true for unrelated imported classes #585 (perry) — cross-module instanceof returns true for unrelated imported classes. drizzle's is(value, kind) brand-check short-circuits with if (value instanceof type) return true; — with this bug, is(table, Subquery) returns true unconditionally and db.select().from(users) crashes with TypeError: Cannot read properties of undefined (reading 'selectedFields') on the wrong-branch read of table._.selectedFields.

2. await thenable returns the thenable itself instead of calling .then(resolve, reject) #586 (perry) — await thenable returns the thenable itself instead of calling .then(resolve, reject). drizzle's QueryPromise lazy-execute pattern (db.select().from(...) returns a builder whose .then() triggers .execute()) needs spec-compliant thenable assimilation. With the current behavior, await returns the builder, query never runs.

3. @perryts/postgres driver — src/transport/net-socket.ts:72 calls net.createConnection(host, port) but perry-stdlib's signature was swapped to (port, host) in v0.5.501 (May 4 2026, 4 days before driver 0.2.1's publish). The driver's comment is stale — it claims perry expects (host, port), but crates/perry-stdlib/src/net/mod.rs:302 binds args: &[NA_F64, NA_STR] (port first, host second, matching Node's actual spec). One-line driver fix; will file PR upstream against PerryTS/postgres.

Test workspace

Lives at test-drizzle-pg/ in the perry repo (untracked). 50-line app.ts, schema + insert/select/update/delete + leftJoin, runs against 127.0.0.1:5432/drizzle_test. Validated end-to-end against Bun (Node strip-types can't read node_modules/**.ts so Bun is the spec-conformance baseline).

What it'll take

#585 + #586 are independent perry-side fixes. #585 is mostly a codegen/runtime correctness fix (codegen ensures cross-module class IDs are non-zero; runtime never matches class_id == 0 as a real class). #586 is a one-shot await-path change: probe .then on the awaited value, dispatch through it if callable. With both landed and the driver patched (independent), this issue closes.

[proggeramlug]

Status update — v0.5.692

#585 (cross-module instanceof) and #586 (await thenable assimilation) both confirmed working in v0.5.692. The driver-side fix shipped as @perryts/postgres@0.2.2. With those three resolved, the acceptance run reaches deeper into the drizzle insert/select path — and surfaces two more perry-side bugs.

New blockers

• Closure body () => new <ImportedClass>(...) inside a compilePackages module fails to link or silently collapses to the class id #588 — Closure body () => new <ImportedClass>(...) inside a compilePackages package either fails to link (Undefined symbols: _node_modules_..._<Class>_constructor) or — in drizzle's actual case — silently emits the class's id as the f64 storage value (typeof _dialect === 'number', value ≈ f64::from_bits(class_id)). Subsequent assignments to the same binding are no-op'd, suggesting the HIR pre-bound it to the class. drizzle's function drizzle(callback, config = {}, _dialect = () => new PgDialect(...)) is the load-bearing repro; I have a clean ~30-line minimal repro under a fake node_modules/repro-pkg2 package in the issue body.

• Object.assign(target, src) drops Symbol-keyed properties already on target #590 — Object.assign(target, src) drops Symbol-keyed properties already on target. Repro is ~10 lines; doesn't depend on cross-module imports. drizzle's pgTableWithSchema writes table[Table.Symbol.Columns] = builtColumns and then runs Object.assign(table, { enableRLS }), which wipes the Symbol-keyed slot. Downstream dialect.buildInsertQuery reads table[Table.Symbol.Columns] as undefined, hitting Object.entries(undefined) and SIGSEGVing in js_object_entries.

Workaround chain to verify the layers

With both bugs patched locally (drizzle's driver.js using const dialect = new PgDialect(...) directly, pgTableWithSchema reordered to set Symbol-keyed properties last), the next blocker is whatever fires inside buildInsertQuery after the Symbol read succeeds — haven't reached that frame yet. Likely either drizzle's complex sql\...`` template literal building or another shape that hits a perry edge.

Where things stand

Step	Status
50-line drizzle program authored	✅
Compile + link clean (6.0 MB binary)	✅
TCP connect to Postgres	✅ (driver fix in 0.2.2)
Schema construction (pgTable users + pgTable posts)	✅
db.insert(users).values({...}) reaches dialect layer	❌ blocked by #588
dialect.buildInsertQuery reads table[Symbol.Columns]	❌ blocked by #590
Insert wire round-trip + select diff vs Node baseline	not yet

Once #588 and #590 land I'll re-run and report the next layer.

[proggeramlug]

Status update — v0.5.697

#588 (closure-class-id) and #590 (Object.assign drops Symbol props) both confirmed working in v0.5.697. Acceptance run advances past pgTableWithSchema setup and reaches dialect.buildInsertQuery. New blocker:

• for (const [i,v] of arr.entries()) silently iterates 0 times when arr is statically typed any #597 — for (const [i, v] of arr.entries()) silently iterates 0 times when arr is statically typed any. Same call on a typed T[] array works (perry has a fast path that synthesizes [i, val] pairs from indices); the dynamic-receiver path falls through to the iterator protocol, where arr.entries().next() returns { done: undefined, value: undefined } instead of { done: false, value: [0, ...] }. Clean ~10-line repro on the issue.

drizzle hits this at pg-core/dialect.js:377 — for (const [valueIndex, value] of values.entries()) where values is destructured from a function param (so its inferred type is any).

Acceptance progress

Step	Status
TCP connect	✅
Schema construction	✅
db.insert(...).values({...}) reaches dialect layer	✅
dialect.buildInsertQuery reads columns + builds insertOrder	✅
for (const [i, v] of values.entries()) iterates	❌ blocked by #597
Insert wire round-trip + diff vs Node baseline	not yet

With a local workaround (rewrite the for-of to indexed loop), the run advances another ~5 lines into buildInsertQuery and hits another Cannot read properties of undefined (reading 'length') further inside the column-default-handling path (likely a sql\default`` template-literal issue or a serial/onUpdateFn dispatch hole). Haven't traced that one yet — once #597 lands I'll re-run on real perry without the patch and report whatever fires next.