/pgjdbc

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

Reviewers

@jorsol jorsol

@bokken bokken

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
  42.2.2
4 participants
@vlsi @codecov-io @bokken @jorsol
@vlsi
Member

vlsi commented Mar 9, 2018 •
edited

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.

Sign in to view

codecov-io commented Mar 9, 2018 •
edited

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.

Sign in to view
Member

vlsi commented Mar 9, 2018

Reviews are welcome, I think the PR is ready.
pgjdbc/src/main/java/org/postgresql/core/v3/SimpleQuery.java
}
int[] getStatementTypes() {
int[] getPrepareTypes() {
return preparedTypes;

This comment has been minimized.

Sign in to view
Copy link
@bokken

bokken Mar 10, 2018

Member

Should this return a clone to prevent mutation?

This comment has been minimized.

Sign in to view
Copy link
@vlsi

vlsi Mar 10, 2018

Member

This is a private API, and there's just one usage. No need to clone.
pgjdbc/src/main/java/org/postgresql/core/Oid.java Outdated
@@ -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.

Sign in to view
Copy link
@bokken

bokken Mar 10, 2018

Member

Could these be initialized to a better size?

This comment has been minimized.

Sign in to view
Copy link
@vlsi

vlsi Mar 10, 2018

Member

It could, however I'm inclined to treat that as over-engineering as it is initialization time only.
pgjdbc/src/main/java/org/postgresql/core/Oid.java
return id;
}
} else {
try {

This comment has been minimized.

Sign in to view
Copy link
@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.

Sign in to view
Copy link
@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.

Sign in to view
Copy link
@jorsol

jorsol Mar 10, 2018 •
edited

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.

Sign in to view
Copy link
@vlsi

vlsi Mar 10, 2018

Member

That is interesting
@bokken

bokken approved these changes Mar 10, 2018
View changes

@vlsi vlsi referenced this pull request Mar 10, 2018

Merged

docs: improve documentation and tests for server-side prepared statements #1135

vlsi added some commits Mar 9, 2018

@vlsi
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
Unverified
The key that signed this is expired.
GPG key ID: 38F47D3E410C47B1 Learn about signing commits
a3ca213
@vlsi
fix: add oid.toUpperCase()
Unverified
The key that signed this is expired.
GPG key ID: 38F47D3E410C47B1 Learn about signing commits
ce4dd09
@vlsi
tests: Oid valueOf/toString tests
Unverified
The key that signed this is expired.
GPG key ID: 38F47D3E410C47B1 Learn about signing commits
2b371c0
@vlsi
style: Long.parseLong -> Integer.parseInt, HashMap initial size
Unverified
The key that signed this is expired.
GPG key ID: 38F47D3E410C47B1 Learn about signing commits
e23d05e
@vlsi
fix: revert Long.parseLong
Unverified
The key that signed this is expired.
GPG key ID: 38F47D3E410C47B1 Learn about signing commits
0b8e8bb
@vlsi
doc: update changelog
Unverified
The key that signed this is expired.
GPG key ID: 38F47D3E410C47B1 Learn about signing commits
b902383

@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

@vlsi @rhavermans
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
6bdef29

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

@vlsi @rhavermans
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
91ac41f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment