I'm submitting a ...
Describe the issue
org.postgresql.core.TypeInfo.getPGType() behavior changed unexpectedly in 42.2.11 for specific types, e.g. for Oid.TIMESTAMP. The method currently returns timestamp without time zone, but before 4.2.11 it returned just timestamp.
Driver Version?
42.2.11
PostgreSQL Version?
11.5
To Reproduce
The following code reproduces the issue:
try (Connection connection = DriverManager.getConnection(dbUrl, dbUser, dbPassword);
BaseConnection baseConnection = (BaseConnection) connection) {
System.out.println(baseConnection.getTypeInfo().getPGType(Oid.TIMESTAMP));
}
Expected behaviour
I expect, as in 42.2.10, to get timestamp as a result. Instead, I get timestamp without time zone. While not exactly an error, this has a significant impact on my code, and may also cause other unexpected compatibility issues.
Apparently, this is the result of the following changes: f554118
Studying the code, the problem seems to be as follows. The changes didn't take into account that the oid, as the 1st element of the TypeInfoCache.types array structure, should actually be unique. This implicitly follows from the constructor code:
public TypeInfoCache(BaseConnection conn, int unknownLength) {
// ...
oidToPgName = new HashMap<Integer, String>((int) Math.round(types.length * 1.5));
The code populates a hash map and uses oid as a key. Lines added in #1719 cause the initial value to be overwritten for some of the keys, resulting in change of behavior.
A quick-and-dirty fix would be to reorder the values in the types array, but probably some more complicated refactoring is needed here.
I'm submitting a ...
Describe the issue
org.postgresql.core.TypeInfo.getPGType()behavior changed unexpectedly in 42.2.11 for specific types, e.g. forOid.TIMESTAMP. The method currently returnstimestamp without time zone, but before 4.2.11 it returned justtimestamp.Driver Version?
42.2.11
PostgreSQL Version?
11.5
To Reproduce
The following code reproduces the issue:
Expected behaviour
I expect, as in 42.2.10, to get
timestampas a result. Instead, I gettimestamp without time zone. While not exactly an error, this has a significant impact on my code, and may also cause other unexpected compatibility issues.Apparently, this is the result of the following changes: f554118
Studying the code, the problem seems to be as follows. The changes didn't take into account that the
oid, as the 1st element of theTypeInfoCache.typesarray structure, should actually be unique. This implicitly follows from the constructor code:The code populates a hash map and uses
oidas a key. Lines added in #1719 cause the initial value to be overwritten for some of the keys, resulting in change of behavior.A quick-and-dirty fix would be to reorder the values in the
typesarray, but probably some more complicated refactoring is needed here.