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.
Expected Behavior
For native Spring Data
@Querystatements, 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 asCAST(: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:
is valid PostgreSQL SQL, but
inetis 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
@Querydeclarations. 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.