Data serialization ·
SQL query formatting and local AST-style pretty-printing
Pretty-printing SQL is a parse-and-reprint transform. The sql-formatter library understands dialects well enough to indent SELECT lists and JOIN chains. It does not open a socket to Postgres. That is the safety property: formatting is not execution. Hosted fiddles that run the query are a different product and a different risk.
Lexer versus full parser
Many formatters are sophisticated lexers with structure, not full SQL grammars. Dollar-quoting and nested comments are traps. When it fails, it should fail visibly.
Never execute
No eval, no WebSQL, no POST to a fiddle with production data. PII in literals stays in the textarea. Same minimization story.
Dialects
Backticks vs double quotes, TOP vs LIMIT, ILIKE. The tool’s dialect selector is a correctness control.
Docs-as-code
Formatted queries in Markdown fences review well (Post 13). Huge dumps belong in files, not tables.
Regex is not a formatter
You cannot reliably indent SQL with regex (Post 16). Use a library. Test on your worst query.
Frequently asked questions
Will formatting validate SQL?
No. Invalid SQL may still pretty-print or may throw. Use a real engine to validate.
Which dialect should I pick?
PostgreSQL, MySQL, T-SQL, and others disagree on quotes and LIMIT. Pick the one that matches production.
Are comments preserved?
Usually yes for -- and /* */ if the formatter is configured to. Do not assume secrets in comments are stripped.