Skip to content
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

@vlsi
Copy link
Member

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

@codecov-io 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
Copy link
Member Author

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

This comment has been minimized.

@vlsi

vlsi Mar 10, 2018
Author Member

That is interesting

@vlsi vlsi force-pushed the vlsi:fix_statement_sharing branch from 5f40cc9 to 8cb15d7 Mar 10, 2018
@bokken
bokken approved these changes Mar 10, 2018
vlsi added 6 commits Mar 9, 2018
…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 force-pushed the vlsi:fix_statement_sharing branch from e09db27 to b902383 Mar 11, 2018
@vlsi vlsi merged commit fcd1ea1 into pgjdbc:master Mar 11, 2018
1 check was pending
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
…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
…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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

4 participants
You can’t perform that action at this time.