Introduce notion of SQL type code

[beikov]

It has come up various times that the JDBC type code was too coarse grained for our purposes and that drivers require certain actions (setNull) to happen with the JDBC type code although we need to differentiate different types with the same JDBC type code. One prime example where this is a problem is when someone uses the PostgreSQL geometry type and also some custom JSON type. In both cases it is necessary to use the getObject/setObject APIs and use the Types.OTHER type code, but these are different JDBC type descriptors. The current JdbcTypeDescriptorRegistry uses the JDBC type code to register type descriptors though. This leads to requiring that the type descriptors are registered under artificial "sql type codes" and provide custom binders/extractors that use the generic JDBC type code Types.OTHER correctly for certain API calls. If we introduce a notion of "sql type codes" in the JdbcTypeDescriptor and it seems JdbcTypeDescriptor#getJdbcTypeCode might just be that (considering there also is JdbcTypeDescriptor#getJdbcType to which the default implementation delegates), we could handle all this generically. Registrations would happen for both codes, but the lookup by JDBC type code would only be used when trying to find the JdbcTypeDescriptor for native query results.

[gavinking]

Yep, I think it's a problem that JdbcTypeDescriptor.getJdbcType() is sometimes interpreted as determining a SQL column type (in DDL generation), and sometimes as determining the way we want to interact with the JDBC API.

These are often but certainly not always the same thing.

So this causes problems and we should separate the two usages.

Even I fucked something up as a result of this confusion.

[gavinking]

I'm going to work on this now.

[gavinking]

See #4105

[maesenka]

I completely agree. As mentioned in the proposal. I've had this problem also. See e.g. HHH-11490 and HH-14683