fix: numeric binary decode for even 10 thousands

[bokken]

binary numeric values which represented integers multiples of 10,000
from 10,000-9,990,000 were not decoded correctly

fixes #2326

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. Does your submission pass tests?
2. Does ./gradlew autostyleCheck checkstyleAll pass ?
3. Have you added your new test classes to an existing test suite in alphabetical order?

Changes to Existing Features:

• Does this break existing behaviour? If so please explain.
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you successfully run tests with your changes locally?

[davecramer]

@bokken thanks! Once this passes we can push it and release later today.

[jorsol]

Can this be tested with a wide set of different scales (not just 20)?

[bokken]

Glad to figure it out. It is a bit of a strange corner case. This binary format for numeric is... interesting.

I am working on additional tests which go through the database, to catch cases where the database's binary encoding might not match how the driver does the binary encoding.

[bokken]

@jorsol we can test with whatever scale we want. It turns out it just matters that it is not 0.

[bokken]

Any other tests to consider?

[bokken]

FAILURE   0.5sec, org.postgresql.jdbc.ScramTest > testPasswordWithoutSpace(String)[1], [1] My Space
    org.opentest4j.AssertionFailedError: expected: <28P01> but was: <08001>
        at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
        at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
        at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1124)
        at org.postgresql.jdbc.ScramTest.testPasswordWithoutSpace(ScramTest.java:99)
FAILURE   1.2sec,   12 completed,   1 failed,   0 skipped, org.postgresql.jdbc.ScramTest

That does not appear to be related to any of these changes, right?

[jorsol]

That does not appear to be related to any of these changes, right?

No, it's not, AppVeyor probably needs an additional configuration for the scram test, probably we could just stick with GH Actions and drop appveyor near in the future.

[davecramer]

What I would like to see is some documentation on where this algorithm came from. But not before we release.

[davecramer]

@bokken I'm inclined to merge this and release. Any reason why I shouldn't ?

[bokken]

@davecramer, I say go for it.

[bokken]

@davecramer, are you wanting more than what is described here:
https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/util/ByteConverter.java#L141-L154

[davecramer]

Well this algorithm must have come from somewhere. Perhaps even adding comments in the code as to what some of the parts are doing ?

It's pretty straightforward what scale and precision are. I don't think we need any more language about that.

[davecramer]

pgjdbc v42.3.1-rc1 is ready for preview.

Git SHA: b3050e6
Staging repository: https://oss.sonatype.org/content/repositories/orgpostgresql-1287

[NikolayMetchev]

I tested with that version and the bug appears to be fixed.