Presented by:
James Sadler
James Sadler is a Principal Engineer at CipherStash, where he works on EQL, a PostgreSQL extension for searchable encryption. His work spans PostgreSQL internals, Rust systems programming, and applied cryptography, including a high-performance PostgreSQL-flavoured SQL parser validated against Postgres's own regression suite. He's based in Sydney and gets a kick out of building software that is correct by construction.
No video of the event yet, sorry!
Almost every tool that touches SQL but isn't Postgres — linters, migration tools, query rewriters, proxies, ORMs, observability pipelines — has to understand the language without a running backend. And almost all of them get Postgres's dialect subtly wrong, because Postgres has one of the most intricate grammars in production software: a multi-thousand-line Bison grammar fused to a lexer that rewrites its own token stream, four categories of keyword with different reservation rules, and operator-precedence corners the project spent decades settling.
This talk is about building a parser that gets Postgres right, and — more interestingly — proving that it does. Rather than a hand-picked test set, I validate against Postgres's own regression suite, treating the canonical parser as ground truth: if Postgres accepts a statement, we must; if our parse disagrees, that's a bug.
I'll walk through the parts that genuinely surprised me — the lexer/grammar coupling and lookahead token-merging that make SQL not quite LALR(1), how keyword categories fall out of the grammar, and the engineering that lets a correct parser also be a fast one: zero-copy lexing, arena-allocated ASTs, and where the time actually goes.
Finally, once you have a faithful AST you have the front-end of a compiler. I'll show how name resolution, type inference, and provably-safe query transformation build on top — turning a parser into something that can reason about and rewrite SQL with confidence.
What you'll leave with:
- Why Postgres's grammar is hard, concretely — and which parts trip up every reimplementation
- A correctness methodology (regression suite as source of truth) you can apply to any SQL tooling
- Practical techniques for making a parser fast without sacrificing fidelity
- How a parser becomes a semantic layer: type checking, analysis, and safe rewriting
- Date:
- 2026 October 30 09:50 +11
- Duration:
- 40 min
- Room:
- Taylor
- Conference:
- PG Down Under 2026
- Language:
- Track:
- Development
- Difficulty:
- Medium