Open Data Infrastructure
SQLGlot Policy Rewrite Checks for SQL Migration
How SQLGlot rewrite checks help catch policy-sensitive SQL changes during migration.
SQL migration is not finished when the query parses in the new dialect.
Policy can hide inside syntax
Most SQL migration work starts with syntax. Can the query move from one dialect to another? Can it parse? Can it run? Those are necessary tests. They are not enough for governed data.
Policy-sensitive logic often hides in predicates, joins, masking expressions, security filters, time-zone assumptions, and UDFs. A migration can preserve the broad query shape while changing who is included, which rows are masked, or what a metric means. That is where SQL rewrite checks matter.
Core idea: SQLGlot policy rewrite checks make migration governance inspect the transformed SQL, not only the fact that SQL was transformed.
SQLGlot works at the parser and transpiler layer
The SQLGlot documentation describes SQLGlot as a SQL parser, transpiler, optimizer, and engine that can translate across dialects. The parser documentation exposes the structured layer that makes policy-sensitive inspection possible.
That does not mean SQLGlot magically proves governance correctness. It means migration teams can compare abstract syntax trees, normalized expressions, translated predicates, and flagged constructs before migrated SQL reaches production.
Compare meaning, not only dialect support
- Identify predicates, joins, masking logic, policy UDFs, and date filters before translation.
- Compare the original and rewritten SQL at the parsed-expression level.
- Flag dropped predicates, changed null behavior, implicit casts, and dialect-specific functions.
- Attach owner review to high-risk rewrites.
- Run sample-row and denial-case tests before production cutover.
This belongs with SQLGlot and ODI migration, portable SQL, and vendor portability tests. Portability has to preserve policy meaning, not just runnable text.
What breaks first
- A filter migrates but changes null or time-zone behavior.
- A masking expression becomes a generic expression with weaker semantics.
- A UDF has no equivalent in the target dialect and gets replaced manually without review.
- Migration tests validate row counts but miss policy-sensitive subsets.
Questions to ask during migration review
- Which parts of the query express policy, not only business logic?
- Can the migration diff show predicate, join, and masking changes?
- Which rewrites require data owner approval?
- Can denial and edge-case rows prove that policy still behaves correctly?
Sources to start with
These primary sources anchor the technical claims in this guide.
A migrated query that changes policy is not a migration. It is a silent rewrite of trust.