New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: wrong results when a single statement is used with UNSPECIFIED types #1137

Merged
merged 6 commits into from Mar 11, 2018

Conversation

Projects
None yet
4 participants
@vlsi
Member

vlsi commented Mar 9, 2018

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

@vlsi vlsi added this to the 42.2.2 milestone Mar 9, 2018

@codecov-io

This comment has been minimized.

codecov-io commented Mar 9, 2018

Codecov Report

Merging #1137 into master will increase coverage by 0.03%.
The diff coverage is 70.37%.

@@             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
@vlsi

This comment has been minimized.

Member

vlsi commented Mar 9, 2018

Reviews are welcome, I think the PR is ready.

}
int[] getStatementTypes() {
int[] getPrepareTypes() {
return preparedTypes;

This comment has been minimized.

@bokken

bokken Mar 10, 2018

Member

Should this return a clone to prevent mutation?

This comment has been minimized.

@vlsi

vlsi Mar 10, 2018

Member

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>();

This comment has been minimized.

@bokken

bokken Mar 10, 2018

Member

Could these be initialized to a better size?

This comment has been minimized.

@vlsi

vlsi Mar 10, 2018

Member

It could, however I'm inclined to treat that as over-engineering as it is initialization time only.

return id;
}
} else {
try {

This comment has been minimized.

@bokken

bokken Mar 10, 2018

Member

Why parse as long and truncate to int rather than just parsing directly to int?

This comment has been minimized.

@vlsi

vlsi Mar 10, 2018

Member

That is interesting. I just replicated existing code. Makes sense to replace with Integer

This comment has been minimized.

@jorsol

jorsol Mar 10, 2018

Contributor

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.

This comment has been minimized.

@vlsi

vlsi Mar 10, 2018

Member

That is interesting

@bokken

bokken approved these changes Mar 10, 2018

vlsi added some commits Mar 9, 2018

fix: wrong results when a single statement is used with UNSPECIFIED t…
…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

@vlsi vlsi merged commit fcd1ea1 into pgjdbc:master Mar 11, 2018

1 check was pending

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details

rhavermans added a commit to bolcom/pgjdbc that referenced this pull request Jul 13, 2018

fix: wrong results when a single statement is used with UNSPECIFIED t…
…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

rhavermans added a commit to bolcom/pgjdbc that referenced this pull request Jul 13, 2018

fix: wrong results when a single statement is used with UNSPECIFIED t…
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment