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: avoid connection failure when DateStyle is set to ISO #1081

Merged
merged 1 commit into from Jan 21, 2018

Conversation

vlsi
Copy link
Member

@vlsi vlsi commented Jan 20, 2018

Default PostgreSQL configuration is DateStyle='iso, dmy',
however just iso would be fine.

Note: PostgreSQL prints DateStyle value in upper case, and toUpperCase
was added just in case.

fixes #1080

Default PostgreSQL configuration is DateStyle='iso, dmy',
however just iso would be fine.

Note: PostgreSQL prints DateStyle value in upper case, and toUpperCase
was added just in case.

fixes pgjdbc#1080
@vlsi vlsi added this to the 42.2.1 milestone Jan 20, 2018
@codecov-io
Copy link

Codecov Report

Merging #1081 into master will increase coverage by 0.07%.
The diff coverage is 50%.

@@             Coverage Diff              @@
##             master    #1081      +/-   ##
============================================
+ Coverage      67.2%   67.27%   +0.07%     
- Complexity     3662     3665       +3     
============================================
  Files           170      170              
  Lines         15622    15623       +1     
  Branches       2523     2524       +1     
============================================
+ Hits          10498    10510      +12     
+ Misses         3937     3928       -9     
+ Partials       1187     1185       -2

@@ -2593,7 +2593,8 @@ public void receiveParameterStatus() throws IOException, SQLException {
value), PSQLState.CONNECTION_FAILURE);
}

if (name.equals("DateStyle") && !value.startsWith("ISO,")) {
if (name.equals("DateStyle") && !value.startsWith("ISO")
&& !value.toUpperCase().startsWith("ISO")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks redundant to check startsWith() first and toUpperCase().startsWith() later.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first one is an optimization

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants