Introduce JDBC-specific dialects in JDBC module

[mipo256]

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.

[mipo256]

I can take a look in here, since I'm already in the context of the problem @mp911de

[schauder]

So far we did this on a as-needed basis. See for example JdbcSqlServerDialect

We DO have an inconsistency here: R2DBC dialects have the same name as their relational counter part, while the JDBC variants have a JDBC dialect.

This is something we could unify for 4.0. i.e. creating new classes and deprecating old ones on main and removing the old ones in 4.0.x

Not sure if we always should create a JDBC variant, even when it just extends the base class.
Opinions?

[mp911de]

Having a JDBC-specific subinterface and distinguishing between the R2DBC dialects makes sense. Dialect specifics make sense on the relational level when considering functionality that is dialect-specific (note: not driver-specific) such as array handling, expressing limit clauses, locks (in the SQL statement) and some more details.

R2dbcDialect considers R2DBC-specifics such as bind-markers. We can already see a need to do the same for JDBC-specifics as the SQLType business.

[mipo256]

What is the solution going to look like @schauder @mp911de ? I can think of adding dialects in the jdbc module that extend the relational counterparts along with JdbcDialect.

[schauder]

Having a JDBC-specific subinterface and distinguishing between the R2DBC dialects makes sense. Dialect specifics make sense on the relational level when considering functionality that is dialect-specific (note: not driver-specific) such as array handling, expressing limit clauses, locks (in the SQL statement) and some more details.

R2dbcDialect considers R2DBC-specifics such as bind-markers. We can already see a need to do the same for JDBC-specifics as the SQLType business.

As written above: the JDBC specific interface already exists and so do JDBC specific implementations.

The differences to the way it is handled in R2DBC are:

1. R2DBC seems to have jdbc specific implementations for all dialects.
2. The naming convention: JDBC uses a JDBC prefix.

[mipo256]

I got it, thanks @schauder, I'll submit a PR shortly