Summary
Currently, SQL syntax errors are only detected after the query is sent to PostgreSQL. Add lightweight client-side syntax validation using the sqlparser crate (already a dependency) to catch obvious errors before execution, providing faster feedback.
Current Behavior
- User writes a query with a typo (e.g.,
SELEC * FROM users)
- User presses F5/Ctrl+Enter
- Query is sent to PostgreSQL
- PostgreSQL returns an error
- Error is displayed in the results panel
Proposed Behavior
- When the user presses F5/Ctrl+Enter, the query is first parsed locally with
sqlparser
- If parsing fails, show the error immediately in the results panel (or status bar) without sending to PostgreSQL
- If parsing succeeds, send to PostgreSQL as normal
- This should be a pre-execution check only — no real-time/as-you-type validation to avoid being clunky or spammy
- Invalid SQL that
sqlparser doesn't catch (e.g., nonexistent tables) still goes to PostgreSQL and gets the existing structured error handling
Design Considerations
- Not a linter or as-you-type checker — only validate on execute to avoid noise
- Fail open — if
sqlparser can't parse a query but it might be valid PostgreSQL-specific syntax (e.g., SHOW, COPY, \ commands), skip pre-validation and let PostgreSQL handle it
- Use
sqlparser::dialect::PostgreSqlDialect for PostgreSQL-specific syntax support
- Show pre-validation errors using the existing
StructuredError display with ErrorCategory::Syntax
- Position/line/column from
sqlparser errors should map to the editor cursor position
- Keep the round-trip to PostgreSQL as the authoritative error source — client-side validation is just a fast shortcut for obvious mistakes
Scope
- Parse with
sqlparser before sending to PostgreSQL
- Map
sqlparser error positions to editor line/column
- Display using existing structured error UI
- Skip pre-validation for statements
sqlparser doesn't support (SHOW, COPY, SET, etc.)
Out of Scope
- Real-time/as-you-type syntax highlighting of errors
- Semantic validation (table/column existence)
- Autocomplete integration
Summary
Currently, SQL syntax errors are only detected after the query is sent to PostgreSQL. Add lightweight client-side syntax validation using the
sqlparsercrate (already a dependency) to catch obvious errors before execution, providing faster feedback.Current Behavior
SELEC * FROM users)Proposed Behavior
sqlparsersqlparserdoesn't catch (e.g., nonexistent tables) still goes to PostgreSQL and gets the existing structured error handlingDesign Considerations
sqlparsercan't parse a query but it might be valid PostgreSQL-specific syntax (e.g.,SHOW,COPY,\commands), skip pre-validation and let PostgreSQL handle itsqlparser::dialect::PostgreSqlDialectfor PostgreSQL-specific syntax supportStructuredErrordisplay withErrorCategory::Syntaxsqlparsererrors should map to the editor cursor positionScope
sqlparserbefore sending to PostgreSQLsqlparsererror positions to editor line/columnsqlparserdoesn't support (SHOW, COPY, SET, etc.)Out of Scope