fix: wrong results when a single statement is used with UNSPECIFIED types #1137
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1137 +/- ##
============================================
+ Coverage 67.38% 67.42% +0.03%
- Complexity 3687 3698 +11
============================================
Files 170 170
Lines 15638 15663 +25
Branches 2531 2539 +8
============================================
+ Hits 10538 10560 +22
+ Misses 3917 3916 -1
- Partials 1183 1187 +4 |
|
Reviews are welcome, I think the PR is ready. |
| } | ||
|
|
||
| int[] getStatementTypes() { | ||
| int[] getPrepareTypes() { | ||
| return preparedTypes; |
bokken
Mar 10, 2018
Member
Should this return a clone to prevent mutation?
Should this return a clone to prevent mutation?
vlsi
Mar 10, 2018
Author
Member
This is a private API, and there's just one usage. No need to clone.
This is a private API, and there's just one usage. No need to clone.
| @@ -76,6 +78,22 @@ | |||
| public static final int REF_CURSOR = 1790; | |||
| public static final int REF_CURSOR_ARRAY = 2201; | |||
|
|
|||
| private static final Map<Integer, String> OID_TO_NAME = new HashMap<Integer, String>(); | |||
| private static final Map<String, Integer> NAME_TO_OID = new HashMap<String, Integer>(); | |||
bokken
Mar 10, 2018
Member
Could these be initialized to a better size?
Could these be initialized to a better size?
vlsi
Mar 10, 2018
Author
Member
It could, however I'm inclined to treat that as over-engineering as it is initialization time only.
It could, however I'm inclined to treat that as over-engineering as it is initialization time only.
| return id; | ||
| } | ||
| } else { | ||
| try { |
bokken
Mar 10, 2018
Member
Why parse as long and truncate to int rather than just parsing directly to int?
Why parse as long and truncate to int rather than just parsing directly to int?
vlsi
Mar 10, 2018
Author
Member
That is interesting. I just replicated existing code. Makes sense to replace with Integer
That is interesting. I just replicated existing code. Makes sense to replace with Integer
jorsol
Mar 10, 2018
•
Member
It's a (int) Long.parseLong(oid); because OIDs in PostgreSQL are unsigned int, using just Integer.parseInt(oid); will break for OIDs larger than 2147483647 with a NumberFormatException.
The cast of a long to an int simulates an unsigned int since Java don't have a primitive unsigned int, in Java 8 there is Integer.parseUnsignedInt(oid); (which more or less do the same cast) but since the driver has still to support Java 6 the (int) Long.parseLong(oid); is the valid option.
It's a (int) Long.parseLong(oid); because OIDs in PostgreSQL are unsigned int, using just Integer.parseInt(oid); will break for OIDs larger than 2147483647 with a NumberFormatException.
The cast of a long to an int simulates an unsigned int since Java don't have a primitive unsigned int, in Java 8 there is Integer.parseUnsignedInt(oid); (which more or less do the same cast) but since the driver has still to support Java 6 the (int) Long.parseLong(oid); is the valid option.
vlsi
Mar 10, 2018
Author
Member
That is interesting
That is interesting
…ypes timestamp, date, are sent as UNSPECIFIED, and pgjdbc did not verify the actual parameter types at parse time. This might cause wrong results if the query was parsed with explicit type (e.g. setString(...)), and then re-executed with TIMESTAMP parameter (timestamps are sent as UNSPECIFIED, thus pgjdbc silently accepted the statement even though it should reparse) fixes #648 closes #674
…ypes (pgjdbc#1137) Timestamp, date (and some other types), are sent as UNSPECIFIED, and pgjdbc did not verify the actual parameter types at parse time. This might cause wrong results if the query was parsed with explicit type (e.g. setString(...)), and then re-executed with TIMESTAMP parameter (timestamps are sent as UNSPECIFIED, thus pgjdbc silently accepted the statement even though it should reparse) fixes pgjdbc#648 closes pgjdbc#674
…ypes (pgjdbc#1137) Timestamp, date (and some other types), are sent as UNSPECIFIED, and pgjdbc did not verify the actual parameter types at parse time. This might cause wrong results if the query was parsed with explicit type (e.g. setString(...)), and then re-executed with TIMESTAMP parameter (timestamps are sent as UNSPECIFIED, thus pgjdbc silently accepted the statement even though it should reparse) fixes pgjdbc#648 closes pgjdbc#674
timestamp, date, are sent as UNSPECIFIED, and pgjdbc did not verify the actual parameter types at parse time.
This might cause wrong results if the query was parsed with explicit type (e.g. setString(...)), and then re-executed with
TIMESTAMP parameter (timestamps are sent as UNSPECIFIED, thus pgjdbc silently accepted the statement even though it should reparse)
fixes #648
closes #674