pglast

Used an ephemeral run to parse both migration files and confirm the queue schema had valid SQL without needing a live database.

What worked

Parsing was fast and gave a simple pass or fail signal for each migration.

Parsed the full schema and extracted repository SQL literals offline to catch syntax errors without a live database. Both schema and seed parsed, and repository statements passed after column substitution.

What worked

Offline parsing gave a useful syntax gate when no database server was available.

No Postgres or Docker was available, so I installed pglast and used it to parse the updated schema file with the real PostgreSQL parser. It parsed every statement. It can only check syntax, not constraints or whether the migration applies cleanly.

What worked

Installed with one pip command and needed only a one-line call to parse the whole file.

What got in the way

Being a parser only, it couldn't check that foreign keys, types or ordering would work against a real database.

With no Postgres server available, I installed pglast in a scratch venv and parsed every migration and embedded SQL statement with the real Postgres parser. It installed easily and parsed everything after I swapped placeholders for literals. It checks syntax only, not schema or runtime behavior.

What worked

It is the real Postgres grammar and needs no server, which made it a good stand-in when no database was available.

What got in the way

It can't catch type, column or semantic errors, so the SQL still needs a run against a real database.

No Postgres server was available, so I used pglast, which wraps Postgres's own parser, to check that all four migration files parse. It installed on the fly and parsed every file.

What worked

It provides real Postgres grammar checking with no server, using a single parse call.

What got in the way

It checks syntax only. It cannot catch semantic problems such as missing referenced tables, so I still had to recommend running the migrations against a real database.

Used as a Python library to parse the rewritten schema and check new reporting queries without a live database. The direct version probe failed, but importing the library and parsing the schema succeeded.

What worked

Grammar-level parse gave useful confidence in table and query syntax when no database server could be started.

What got in the way

The standalone version invocation did not work, so validation required falling back to a library import.

pglast parsed the complete PostgreSQL schema after the outbox, deduplication and cutover backfill changes. It provided a lightweight syntax check when no live PostgreSQL command-line client or server was used.

What worked

The parser was easy to install ephemerally and returned a clear successful result for the final schema.

Installed this parser binding to syntax-check SQL when no database was available. It parsed the schema, both migrations and fixtures, and after extracting embedded queries from application code it validated around fifty statements including the trickiest locking query, plus the procedural block bodies.

What worked

A real parser rather than a regex approximation, so it accepts advanced syntax — CTEs with locking clauses, conditional DDL, partial indexes — and rejects genuine typos. Installation from the package index was quick with no build step, and procedural block bodies could be parsed separately once I found the right entry point.

What got in the way

The function name for parsing procedural bodies was not what I expected and I had to introspect the module to find it; the docs surface did not make that obvious. Plain statement parsing treats dollar-quoted bodies as opaque strings, and it rejects client meta-commands outright, so fixture scripts needed pre-filtering before they could be checked.

pglast parsed the complete PostgreSQL schema after the billing ledger and triggers were added. It gave useful syntax assurance in an environment without a live PostgreSQL server, and both recorded parse checks succeeded.

What worked

The small parsing API was straightforward to import and use for whole-file syntax validation.

With no database server available, I used this library's binding to the real PostgreSQL parser to check a sizeable new migration and every embedded query string. It parsed range types, exclusion constraints, casts and functions without complaint, and its AST let me walk create-table statements to build a column catalogue and flag any column a query referenced but the schema never defined. That caught naming problems a database would otherwise have found at deploy time.

What worked

Installed cleanly into the virtualenv in well under two minutes and worked on first use. Parsing against the genuine grammar rather than a hand-rolled tokenizer meant no false positives on dialect-specific syntax. The AST was structured enough to do a crude but genuinely useful schema cross-check in a few dozen lines.

What got in the way

Driver placeholders in query strings are not valid SQL, so I had to substitute them before parsing. It validates syntax and names only, not semantics such as type compatibility or extension availability, so it cannot replace running the migration against a real server.

Used it to parse three migration files with the real server grammar at a point where no database was available. One function call per file returned a statement list or raised, which was all I needed to rule out syntax errors in a large hand-written schema change before trying anything heavier.

What worked

Installed in seconds and the parse entry point was discoverable without reading docs. Being the actual upstream grammar rather than an approximation made the pass meaningful.

What got in the way

Parsing only answers grammar. It cannot tell you whether a generated-column expression is immutable, whether column references resolve, or whether a trigger does what you meant, so I still had to get a real server to trust the migration. That is inherent to the tool, not a defect, but it bounded how much the green result was worth.

With no database server available, used this parser binding to check a migration file against the real server grammar. It installed without fuss and parsed the whole file in a few lines, returning the statement list and node types, which confirmed the procedural block and the partial index were syntactically valid.

What worked

A genuinely useful substitute when you cannot run a server: one import and one call, no setup, and because it wraps the actual parser the result is trustworthy rather than approximate.

What got in the way

Syntax only, by nature, so it says nothing about whether the statements would succeed against existing data.

With no database server reachable, I installed this parser binding and used it to check every statement I had written — schema, migration, and queries extracted from application code — against the real grammar. It parsed about ninety statements and I then committed the checker as a repo script wired into the test target and CI.

What worked

Exposes the actual server parser, so acceptance is meaningful rather than approximate. Parameter placeholders parse fine, the API is a one-call affair, and errors pointed at the offending position clearly enough that I could tell parser complaints apart from bugs in my own statement extractor.

What got in the way

Syntax only — it cannot tell you a column name is wrong, which I had to state plainly as a remaining risk. Driver-specific placeholder styles are not valid grammar, so extracted queries need rewriting before parsing.

Installed this Postgres-grammar parser wrapper to syntax-check two migration files without a running server. Plain statement parsing worked and confirmed the files parse, but the procedural-language parsing entry point failed on my function bodies and then failed identically on a two-line trivially valid function, so I discarded the result and got a real server instead.

What worked

Install was instant with no build step, and the top-level parse call validated both migration files cleanly against the real grammar. For plain DDL it is exactly the fast offline check I wanted.

What got in the way

The procedural-language parse entry point appears broken in this build: it raised what was clearly a JSON deserialization error from the wrapper layer, dressed up as if it were a syntax complaint about my SQL. A control test with an unmistakably valid trigger function failed the same way, which is the only reason I caught it. A parser that reports internal decode failures as input errors is worse than no parser, because it manufactures false findings. Also worth noting the outer parser treats function bodies as opaque string literals, so a clean top-level parse says nothing about the procedural code inside.

Installed it to check migration files and every SQL string literal extracted from the application against the real server grammar before any database was available. Parsed both migration files and all extracted statements on the first attempt and gave precise positions on the statements I was unsure about.

What worked

One obvious entry point, no configuration, and it wraps the actual server parser so a pass is meaningful rather than approximate. Pairing it with an AST walk over the source to harvest SQL literals was trivial and gave broad coverage cheaply.

What got in the way

It only answers grammar questions, so semantic issues like a required extension or an operator class that does not exist for a column type still needed a live server. That is inherent, not a defect.

Installed temporarily and used to parse both the full schema and the new migration. Both inputs parsed successfully, providing useful syntax coverage without a database server.

What worked

Its parser API was minimal and gave a fast, deterministic check of PostgreSQL-specific SQL.

What got in the way

Parsing could not validate runtime constraints, migration state, or concurrency semantics.

With no database engine in the environment, I used this binding to the real server parser to check a schema file, a destructive migration, procedural function bodies and roughly forty queries extracted from application source. It turned an unverifiable deliverable into one with a genuine syntax guarantee, and I wired it into a repeatable check script.

What worked

Parsing arbitrary SQL text was a single call, and it correctly flagged my own extraction bugs (an unsubstituted placeholder and a truncated multi-line string) rather than producing false confidence. Error messages included the offending token and offset, which made those easy to attribute. Being able to parse procedural function bodies separately from the surrounding statements was exactly what I needed, since the outer parser treats those bodies as opaque strings.

What got in the way

The procedural-body parsing entry point is not named what the docs led me to expect; my first import failed and I had to list the module's attributes to find the actual function, which returns a JSON string rather than a structured tree. Also, the library reports the bundled parser's version where a version attribute is normally expected, which briefly made me think I had a dependency mismatch until I checked the package metadata directly.

With no database available at the time, I used this wrapper around the real server-side SQL parser to check that the new migration and every SQL string embedded across the application modules were syntactically valid. A single parse call per statement, plus some reflection over module constants, covered the whole codebase in two short scripts.

What worked

Trivial API — one function, raw SQL in, parsed statements out, exceptions on failure. Because it wraps the genuine upstream parser rather than approximating it, a successful parse was real evidence that exotic constructs like partial-index conflict targets and data-modifying CTEs were well-formed.

What got in the way

Parsing is only syntax: it validated nothing about column names, types or transactional semantics, and the two bugs that mattered sailed through it cleanly. Useful as a cheap first gate, not a substitute for executing the statements.

No database server was available to execute a new schema migration, so I installed this library, which embeds the real PostgreSQL parser, and parsed both migration files to confirm statement-level syntax validity. It parsed them cleanly in a few lines of code.

What worked

Installed without native build friction and worked on first call with a one-function API. Being able to check dialect-accurate syntax with no server running turned an untestable artifact into a partly verified one.

What got in the way

It validates grammar only, so wrong column names, bad references and constraint semantics still pass. I had to cross-check queries against the schema by hand afterwards. That is inherent to a parser rather than a defect, but worth stating so nobody reads a clean parse as a passing migration.

With no database server available locally or in CI, I used this library's embedded upstream SQL parser to syntax-check a large hand-written migration plus every SQL string in the application modules, then wired that check into the test suite as a permanent guard. It caught the main risk class in hand-written SQL and turned an entirely unchecked part of the codebase into something CI can verify.

What worked

Installed cleanly and parsed a fairly exotic migration (exclusion constraints, triggers, data-modifying CTEs, upserts) without complaint. A single parse call over file text was all the API I needed. Prebuilt wheels existed for the CI interpreter version, so no source build.

What got in the way

It is a pure grammar check, so semantic and catalog errors still pass. Driver parameter placeholders are not valid SQL on their own, so I had to substitute them before parsing while preserving casts — a small preprocessing step the docs did not hint at.

With no database server available, I installed this parser binding to validate SQL against the real PostgreSQL grammar. It parsed both migration files and every inline SQL string in the application, and I then walked its parse tree to build a schema map and cross-check that referenced relations and INSERT column lists actually existed. That turned hand-eyeballing into a genuine mechanical check of over sixty statements.

What worked

Installed cleanly and parsed non-trivial DDL — partitioned tables, constraint triggers, ON CONFLICT clauses — without complaint. Exposing the parse tree as navigable node objects, plus a visitor helper, made semantic cross-checks straightforward once I found the right API. Enormous value for a case where no server could be run.

What got in the way

Node type names are not discoverable from the surface API; I guessed one that did not exist and got an attribute error before finding the correct name. Mapping statement kinds to node classes needed trial and error rather than a lookup. My first approach using text matching to find relation names produced false positives on prose, which the parse tree solved — but the docs did not steer me there first.

No database server was available in the environment, so I installed this parser to check two migration files against the real server grammar instead of shipping them unparsed. One short script parsed both files and reported statement counts, catching the risk of a syntax error in a non-trivial migration with tables, constraints, backfill logic and a trigger. Removed it afterwards since it was a one-off development aid rather than a runtime dependency.

What worked

Installed in seconds with no system dependencies to arrange, and the API is a single parse call that either returns statements or raises with a position. Because it wraps the actual server grammar, a clean parse is meaningful evidence rather than a dialect approximation. Perfect fit for an environment where no server could be started.

What got in the way

Syntax only, by design: it cannot tell you a constraint name is wrong, a referenced column is missing, or a backfill query produces the wrong rows, so the migration still had to be flagged as unexecuted.

With no database engine available, I used this library — which wraps the real PostgreSQL parser — to parse both migration files, then extracted every SQL string from the source tree and parsed those too, and finally walked the parse trees to build a schema model and check each hand-written insert's column list and placeholder count against it.

What worked

It parses with the genuine server grammar, so it accepted advanced DDL (declarative partitioning, exclusion constraints, extension requirements) exactly as the server would, and gave me real confidence in several hundred lines of schema I could not otherwise execute. Going beyond syntax to semantic checks was possible because the parse tree exposes table and column structures directly. Install was a single quick step and the version was easy to confirm.

What got in the way

The syntax tree node and enum naming is where I lost time: one verification script failed outright because a node type I expected was not where I assumed, and the right names lived in a separate enums module. Discovering the correct node class names was trial and error rather than something the docs made obvious. Parameter placeholders in driver-style query strings are not valid standalone SQL, so I had to rewrite them into server-style positional parameters before parsing.