The problem became evident while working on the following PR #2024.

We have a Dialect interface abstraction, that resides in the relational module. That makes sense, since several capabilities can be re-used in both jdbc and r2dbc modules. We then have a common dialects (that also reside in the relational module) like PostgresDialect or H2Dialect.

For r2dbc, there is no problem - we have a separate PostgresDialect class, that resides in the r2dbc (!) module, and that extends the PostgresDialect in relational module. Therefore, the r2dbc's PostgresDialect can use all the features that reside in the r2dbc module, as it should.

In case of jdbc - we have a problem. The dialects that we use in jdbc module are really placed in the relational module. That becomes a big deal, when we want (and we probably should want) to use some jdbc specific functionality (like java.sql.SQLType) in the dialect that is supposed to be used in spring-data-jdbc.

Soltuion: the way the dialecfts are now structured in r2dbc is the right way to go in my opinion, and in jdbc module we should not use the dialects in relational module, we should provide classes that extend them in the jdbc module, so we can allow these dialects to use jdbc-specific features.