Code review now flags SQL that breaks when your schema changes
2 hours ago
Version 14.2.0 teaches /code-review to read your SQL. A new sql-review agent flags statements that work today and break after a harmless schema change, or that run without an error and return the wrong rows. It ships with 17 rules, and it reads SQL files as well as SQL written inside your application code.
Ask about this presentation
Chapters
Show transcriptHide transcript
Version 14.2.0 teaches /code-review to read your SQL. A new sql-review agent flags statements that work today and break after a harmless schema change, or that run without an error and return the wrong rows. It ships with 17 rules, and it reads SQL files as well as SQL written inside your application code.
The lead rule is positional INSERT. The flagged statement has no column list, so values land in columns by position. When a migration adds, drops, or reorders a column, it fails with a column count error or loads a value into the wrong column. The commented-out line is ignored. Naming the columns keeps the statement safe.
Two of the correctness rules are errors. Comparing a column to NULL with an equals sign never matches, because the comparison is always unknown. A DELETE with no WHERE clause changes every row in the table. NOT IN over a subquery is a warning. If that subquery returns a single NULL, the whole query returns nothing.
The migration rules are mostly errors. A rename or drop breaks the previous application version, which keeps running during a rollout and after a rollback, and a drop destroys the data. The fix is to add the new column first, backfill it, and remove the old one in a later release. The same family also catches a new NOT NULL column with no default, and a column narrowed from bigint to int.
The index rules catch predicates that stop the database using an index. Wrapping a column in LOWER means a plain index can't be used, so the query scans the table. Add an expression index, or compare the bare column. A LIKE pattern that starts with a percent sign has no prefix to seek, so the database reads every entry. Use a prefix match instead.
It also finds SQL inside Python, TypeScript, JavaScript, C#, and Java files. It scans string literals, never comments, and only when they look like SQL. Concatenated or interpolated strings can't be scanned as written, so they're counted as skipped. T-SQL and Postgres rules fire only in files of that dialect, which the detector infers, or you set with the dialect flag.
The notes mark nothing as breaking, but your reviews will change. Whenever a changeset contains SQL, code review now dispatches sql-review. A single error-level hit makes that lens report fail. ORM query builders are out of scope, and injection and N+1 queries stay with the security and performance reviewers. To silence one rule on one statement, add a SQL comment with sql-review, ignore, and the rule id, on the same line or the line before.
Upgrading is a version bump in the dev-team plugin, from 14.1.0 to 14.2.0. Wait if a code review verdict gates your merges and your repository holds unreviewed SQL, because the first run can report errors. Otherwise, point code review at a change that touches SQL. It now flags SQL that breaks when the schema changes.
