Live PostgreSQL syntax checking for ```sql code blocks in Markdown files.
Errors show up as red squiggles as you type, exactly like any other linter — powered by
libpg_query, the actual PostgreSQL parser
extracted from the server source (the same library behind the pg_query Ruby gem).
That means the error messages match what psql would tell you, with accurate line and
column positions.
Course material, homework assignments, and documentation sometimes embed SQL in Markdown
code fences. Every SQL linter we could find wants a .sql file
(SQLFluff explicitly declined markdown support),
and "inline SQL" extensions target strings inside Python/Go/JS — not Markdown.
This extension fills that gap.
- Lints every
```sql/```postgresql/```pgsqlfence on open and as you type (debounced) - Real PostgreSQL syntax errors with exact positions, squiggle on the offending token
- Heuristic
Hint:lines for common mistakes — trailing comma beforeFROM, keyword typos (SELEC→ "Did you mean SELECT?"), unclosed parentheses, reserved words used as table names - Style suggestions (blue squiggles, clearly worded as suggestions — never errors):
keyword capitalization, terminating semicolons,
SELECT *. Defaults follow sqlstyle.guide; every rule is configurable or can be switched off, and safe fixes are offered as one-click lightbulb actions - Multi-statement blocks supported
- Pure-WASM parser bundled with the extension — no Python, no database, nothing to install
~~~fences, longer fence markers, and case-insensitive info strings all handled
| Setting | Default | Description |
|---|---|---|
markdownSqlLint.enable |
true |
Master switch |
markdownSqlLint.fenceLanguages |
["sql", "postgres", "postgresql", "pgsql"] |
Fence info strings treated as SQL |
markdownSqlLint.debounceMs |
300 |
Idle delay before re-linting |
markdownSqlLint.rules.keywordCase |
"upper" |
Suggest upper/lower keyword case, or off |
markdownSqlLint.rules.requireSemicolon |
true |
Suggest terminating semicolons |
markdownSqlLint.rules.discourageSelectStar |
true |
Suggest naming columns instead of SELECT * |
Style rules are suggestions by design: they render as blue info squiggles (never red), their messages start with "Suggestion:", and they only appear on blocks that already parse — a block with a syntax error shows exactly one problem, the error.
Like a .rubocop.yml, you can commit house style with a project: put the
markdownSqlLint.rules.* keys in the workspace's .vscode/settings.json and everyone
opening that folder gets the same conventions.
- Syntax only.
SELECT * FROM tabel_with_typoparses fine — the parser can't know your schema. Semantic checks (unknown table/column) would need a live database; planned as an opt-in feature. - One error per block. The parser stops at the first syntax error in a block (subsequent blocks are still checked independently).
- PostgreSQL dialect. MySQL/SQLite-specific syntax will be flagged. Other dialects would need a different parser backend.
Bug reports, hint heuristics, and dialect ideas welcome — see CONTRIBUTING.md for setup and the extension-testing workflow.
MIT