SQL Formatter

A formatter that uppercases keywords by matching whole words with a regular expression has no way to know whether a given occurrence of "order" is the SQL keyword `ORDER` (as in `ORDER BY`) or a literal string value that happens to contain that word — a query filtering rows `WHERE description = 'the order from stock'` has the word "order" sitting inside a quoted string, not functioning as a keyword at all. A naive formatter uppercases every matching word regardless of context, corrupting the literal string value into `'the ORDER FROM stock'` and silently changing what the query actually filters for. Tokenising the query properly — recognising quoted string boundaries before deciding what counts as a keyword — is what prevents this, and it is precisely the class of bug that only surfaces on real data containing words that happen to collide with SQL keywords, which is why it is easy to miss in testing with simple example queries.

This tool recognises the common clause structure shared across PostgreSQL, MySQL, SQL Server, SQLite and Oracle — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY and their relatives — well enough to indent each clause onto its own line and nest subqueries correctly. It does not build a full understanding of any one database's complete grammar, including vendor-specific extensions like PostgreSQL's array syntax or SQL Server's `TOP` clause placement. The practical consequence is that dialect-specific syntax passes through the formatter untouched rather than causing an error, but it also will not receive the same careful indentation the common clauses do — a reasonable trade for supporting five dialects with one formatter rather than needing a separate tool per database engine.

SQL keywords are case-insensitive by the language specification itself — `SELECT`, `Select` and `select` are identical to every SQL engine — which is precisely what makes uppercasing or lowercasing them a purely cosmetic operation with zero risk of altering behaviour. The same is true of the whitespace and line breaks this formatter adds: a query spread across twelve indented lines executes identically to the same query jammed onto one. Nothing about formatting touches the actual tokens that determine what tables are read, what conditions filter rows, or what values get inserted — only how that same logical query is visually laid out for a human reading it afterwards.

A query generated by an ORM, exported from a database GUI, or written as a single sprawling line during a rushed migration is often functionally correct but genuinely hard for a person to review as written — a fifteen-join query with no line breaks makes it difficult to see which conditions belong to which join, or whether a WHERE clause is filtering the right table. Reformatting it with each clause and each join on its own line, indented to reflect the query's actual structure, is frequently the fastest way to actually understand what a long generated query is doing before approving it in a code review or debugging why it returns the wrong rows.