spring-projects / spring-projects/spring-tools

Allow overriding the SQL dialect used to validate native @Query statements

Open
#1,975 0 comments 0 reactions 1 assignee View on GitHub

@BoykoAlex is already working on this.

Since Aug 26, 2026.

for: eclipse for: vscode theme: spring-data-support theme: validation type: enhancement
Dominant language
Java
Stars
983
Forks
240
Avg merge
7d 1h
Merged PRs (30d)
7

Description

Expected Behavior

For native Spring Data @Query statements, Spring Tools should select the SQL parser/validator from the actual database dependency or provide an explicit way to choose the dialect. A project using PostgreSQL should validate and highlight PostgreSQL-specific syntax such as CAST(:managementIp AS inet) correctly.

Current Behavior

Native queries are parsed as MySQL when a MySQL/MariaDB JDBC driver is present on the classpath, even if the query targets PostgreSQL. The current dependency-based selection prioritizes MySQL/MariaDB over PostgreSQL, and there is no per-project, datasource, repository, or query-level setting to override the selected dialect.

For example:

@Query(value = "SELECT * FROM machine WHERE management_ip = CAST(:managementIp AS inet)", nativeQuery = true)

is valid PostgreSQL SQL, but inet is reported incorrectly when the query is parsed using the MySQL grammar.

Context

Projects can legitimately include more than one JDBC driver—for example, because of migration tooling, tests, integrations, or multiple datasources. In that situation, classpath inference alone is ambiguous and its current MySQL-first precedence causes false syntax diagnostics for PostgreSQL native queries.

Please add an explicit SQL dialect configuration/override, ideally supporting project or datasource scope and, if feasible, individual native @Query declarations. This would complement the classpath inference introduced by #1273 and prevent valid vendor-specific SQL from being validated against the wrong grammar.

Related: #1273 and #1236.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.