Fix issue #2215 - handle OIDs >= 2**31

[MMeent]

Correctly handle the non-signedness of OIDs in relation to signed java integers in this new OID-based type storage.

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?

Changes to Existing Features:

• Does this break existing behaviour? If so please explain.
  Previously, OIDs >= 2**31 could not be handled by the driver. This was exposed in 42.2.23, when OIDs became the primary source of truth about type information (before that version this was the type string).

• Have you added an explanation of what your changes do and why you'd like us to include them?
  This patch fixes the bugged behaviour of 42.2.23, and other misbehaviours with int-typed OIDs by first casting the oids to positive Long values, such that the full OID space is represented in integer values, and can be handled correctly.

• Have you written new tests for your core changes, as applicable?

• Have you successfully run tests with your changes locally?

[codecov-commenter]

Codecov Report

Merging #2217 (67fc988) into master (67fc988) will not change coverage.
The diff coverage is n/a.

❗ Current head 67fc988 differs from pull request most recent head adde580. Consider uploading reports for the commit adde580 to get more accurate results

@@            Coverage Diff            @@
##             master    #2217   +/-   ##
=========================================
  Coverage     70.75%   70.75%           
  Complexity     4383     4383           
=========================================
  Files           200      200           
  Lines         18394    18394           
  Branches       3021     3021           
=========================================
  Hits          13014    13014           
  Misses         3977     3977           
  Partials       1403     1403           

[MMeent]

I can't fully validate this PR because I don't have a system on-hand that has had 2**31 OIDs allocated.

However, the paths that got updated in #1949 to use OIDs should now be able to correctly handle OIDs > 2**31 - 1, so we should now be able to connect to databases which have such large OIDs without the driver crashing on those large values.

[davecramer]

Hmm... I haven't looked fully at the patch, but can't we fake it somehow to create an oid greater than 2**31?

[MMeent]

seeing that we use pg_catalog.pg_type instead of pg_type in getSQLTypeQuery, I don't think we can shadow that table to fake an oid greater than 2**31.

Other than that, OIDs are system-assigned, so to guarantee such high values for OIDs we'd need to create somewhere in the order of 2**31 objects, which would take a long time.

[davecramer]

select 3539503657::oid;
oid

3539503657

seems to work

[MMeent]

Yes, getSQLType(3539503657) is a path we can still test, but we can't put 3539503657::oid in the path that broke for #2215 without generating somewhere near 2**31 entries in the pg_catalog.pg_type table or otherwise manipulating the postgresql clusters' oid counter.

[davecramer]

Yes, getSQLType(3539503657) is a path we can still test, but we can't put 3539503657::oid in the path that broke for #2215 without generating somewhere near 2**31 entries in the pg_catalog.pg_type table or otherwise manipulating the postgresql clusters' oid counter.

This is still of value to make sure that we are properly decoding an unsigned int

[davecramer]

As soon as this passes I will push it, I will also backpatch it into the 42.2.x branch

[MMeent]

I'm quite suprised with this failure in appveyor, as it is in a part of the code I haven't touched.

The error that was thrown was not INVALID_PASSWORD("28P01"), but CONNECTION_UNABLE_TO_CONNECT("08001"). I wouldn't know why only this one connection failed while the rest had no issues, and I haven't been able to reproduce this issue locally against pg10.

[davecramer]

I'm not too concerned about appveyor failures at the moment, Although history suggests I should be.

Thanks