pg-query-emscripten

With no database server and no way to install one, I used this wasm build of the real Postgres parser to grammar-check every SQL statement the change shipped — schema, migration, and statements embedded in TypeScript. All thirty-six parsed, including a data-modifying CTE and a multi-table update with a join and a returning clause. I verified the count independently so nothing was silently skipped.

What worked

It is the actual server grammar, so a clean parse is meaningful rather than approximate. It handled modern constructs without complaint and gave a structured error field that was easy to branch on. Installing it unsaved and running it from a throwaway script was a good fit for a one-off audit.

What got in the way

The module's export shape was not obvious: requiring it returns an object whose initializer lives on the default property, and calling the module directly fails with a bare 'is not a function' error that points nowhere useful. I had to introspect the exports interactively to find the entry point. Worth saying up front in the readme.

Installed the WebAssembly build of the real server parser so embedded query strings and both schema files could be checked against the actual grammar in an environment with no database. It confirmed all extracted statements parse, including range-type exclusion constraints and chained writable CTEs.

What worked

Being the genuine upstream grammar rather than a reimplementation is the whole value: it accepts the advanced constructs a generic SQL linter would reject, and a parse failure is a real failure. Install was quick and it ran fine as a plain script dependency outside the project tree.

What got in the way

The module export shape was not discoverable from the package surface. My first script assumed the top-level export was the parser and failed; it took two separate probe scripts to learn that the usable entrypoint is a default export that must be called and awaited to get the instance, with the parse method hanging off that. A one-line usage example in the readme would have saved the detour. Also worth stating plainly: it proves syntax only, nothing about table or column resolution.

Installed this WebAssembly build of the real Postgres parser to check every schema statement, migration statement and inline query in the codebase when no database server was available. It parsed both DDL files and all of the inline queries, and I layered a column-name resolution check on top of its output.

What worked

It is the actual server grammar, so a pass means something, which is far better than eyeballing SQL. Install was a single command with no native build step, initialization was one call, and it handled numbered placeholders without any preprocessing. Combined with an AST pass over the source to extract queries, it gave complete coverage rather than sampled coverage.

What got in the way

It validates grammar only, not semantics: it says nothing about whether a column exists, a type resolves, or a constraint name matches, so I had to build the catalog cross-check myself. The package has very little usage documentation, so the initialization shape and result structure were worked out by inspection.

With no database server available, used this WASM build of the real Postgres grammar to parse-check both migration files and a hand-written aggregate query with placeholders substituted. It validated the syntax and statement structure of everything, which was the best available substitute for actually applying the migration.

What worked

No native build step and no server needed, which was the whole reason to reach for it. It parses the genuine grammar, so partial indexes, cascading constraints and correlated subqueries were all checked for real rather than eyeballed. Parse results were detailed enough to confirm the expected statements, not just absence of errors.

What got in the way

The module entry point was not obvious: the straightforward require-and-construct pattern failed outright, and the fix was to reach for the default export on the namespace object. A short usage snippet covering both module systems in the readme would have avoided a failed run and a round of introspection. It only validates syntax, so semantic errors would still slip through.

Installed this WebAssembly build of the real Postgres parser to check that every statement I had written — schema DDL, a transactional upsert, and a ranking query with a window function — parses, since no database was available to run them against.

What worked

Once initialised it did exactly the job: parsed roughly a dozen statements against the genuine Postgres grammar, which is far stronger evidence than eyeballing SQL. Installing it into a scratch directory kept it out of the project's dependency tree.

What got in the way

The module's shape was not discoverable. My first attempt failed with a bare 'not a function' error because the parser hangs off a default export that must be called and awaited to initialise the WebAssembly module first. It took two exploratory runs inspecting exported keys to work that out. It also validates syntax only — column resolution and extension operator binding still require a live server, which is easy to over-trust.

With no database server available, I installed this WebAssembly build of the real Postgres grammar to syntax-check a large payments migration. It parsed every statement and, importantly, also validated the bodies of eight stored procedures, which the outer parser would otherwise have treated as opaque strings. I deliberately fed it deliberately-broken procedure code first to confirm the check had teeth before trusting it.

What worked

Actual Postgres grammar rather than an approximation, so it catches real syntax errors including inside dollar-quoted procedure bodies. Fast, pure-npm install with no native toolchain or server needed. Became a reliable re-runnable gate after every migration edit.

What got in the way

The module's export shape was undocumented and took three attempts to discover — the usable initializer sits behind a default export returning a promise. The procedure-parsing result field is a JSON string whose empty case is not an empty array, so my first checker crashed on a parse error with a message that gave no hint about the source. Both cost more time than the parsing itself. Worth noting it only validates syntax; column and constraint references still went unverified.