test(trilean-sql): check the same compiled fragments against PGlite, which needs no Docker - #19
Merged
Merged
Conversation
…which needs no Docker PGlite is PostgreSQL compiled to WebAssembly and run in process, so every construct the postgres dialect emits reaches the same parser and planner, but nothing measured that: the dialect's only executing suite was the container-backed one. pglite.test.ts is that suite's parity harness case for case -- the same seeded subjects fixture and subjectOptions, the same dual execution of each tree through the compiled SQL and through evaluatePredicate per row, the same adversarial set (NULL propagation and absorption, the empty memberOf encoding under negation, NaN, injection via a value and via a hostile columnFor identifier, the deep mixed tree) -- driven through PGlite's own in-process query() instead of testcontainers and pg. Kept a near-verbatim copy rather than a harness parameterised over both engines: agreement by construction is the one thing a parity suite cannot establish. It also makes the three-valued claim measurable on a machine with no Docker daemon, which until now no suite was.
Mearman
marked this pull request as ready for review
September 3, 2026 15:07
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
🎉 This PR is included in version 1.0.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
trilean-sql's integration suite is the only thing that turns the three-valued-logic claim from a design statement into a measured one — asserting that("age" > $1)is indeterminate-preserving is a claim about PostgreSQL's planner, not about the string. Until now that suite needed a working Docker daemon, so on any machine without one the claim went back to being asserted rather than measured, and the package's own README had to say so.This adds
test/integration/pglite.test.ts, the same parity suite against PGlite. PGlite is not a Postgres-compatible reimplementation or a dialect of its own — it is PostgreSQL's own source compiled to WebAssembly and run in process.select version()from it reports:Same parser, same planner, same
NULLsemantics. So every construct the compiler emits underdialect: "postgres"—$N::typecasts,~/!~, double-quoted identifiers,NULL::boolean— is handled by the same code that handles it on a server, anddialect: "postgres"needs no new value for it. That is what makes this a parity suite rather than a smoke test: it is worth executing every case, because executing every case is what establishes PGlite as a verified target of the dialect instead of an assumed one.The two files are a near-verbatim structural copy of each other on purpose. A shared harness parameterised over both engines would make them agree by construction, and agreement by construction is the one thing this cannot establish — the point is that two independently-driven executions of the same compiled SQL land on the same rows. The divergence between the files is confined to how a connection is opened and a statement is run; the column fixture (
src/test-support/columns.ts) is genuinely shared, as it already was with the unit suite.Both files live in the same vitest
integrationproject rather than getting one project each, because they are the same tests:vitest run --project integrationis the whole integration surface, and a third engine would be a new file rather than new configuration.pnpm test:integrationnow runs 38 cases, 19 per engine, and CI's existing Integration job picks the new file up with no workflow change.Nothing under
src/is touched, andpostgres.test.tsis byte-for-byte unchanged — the container-backed suite stays exactly as it was, still the reference the WASM build is being checked against. Incidentally the two now disagree on nothing across two Postgres majors: the container runspostgres:17-alpine, PGlite is built from 18.3.