Skip to content

fix(pg-protocol): read ParameterDescription type OIDs as unsigned - #3728

Open
pratik-desgn wants to merge 1 commit into
brianc:masterfrom
pratik-desgn:fix-parameter-description-oid-uint32
Open

fix(pg-protocol): read ParameterDescription type OIDs as unsigned#3728
pratik-desgn wants to merge 1 commit into
brianc:masterfrom
pratik-desgn:fix-parameter-description-oid-uint32

Conversation

@pratik-desgn

Copy link
Copy Markdown

While digging into #2974 (custom-type OIDs above the int4 range not parsing correctly), I found that path is actually already fixed — parseField() in pg-protocol's parser reads dataTypeID with reader.uint32(), and there's already a regression test (bigOidDescBuff/expectedBigOidMessage) covering an OID over 2^31-1 in RowDescription.

parseParameterDescriptionMessage() never got the same fix though. It still reads each entry in dataTypeIDs with the signed reader.int32(), so a prepared statement parameter whose type OID exceeds 2^31-1 (custom extension types can get OIDs that high) comes back as a negative number instead of the real OID.

This mirrors the RowDescription fix exactly: swap int32() for uint32(), and add the same kind of big-OID regression test for ParameterDescription that already exists for RowDescription. Confirmed the new test fails on the old code (asserts a negative dataTypeID) and passes with the fix; full pg-protocol suite (78 tests) is green.

parseField() already reads dataTypeID as uint32 for RowDescription
(with a regression test covering OIDs above 2^31-1), but
parseParameterDescriptionMessage() was still using the signed int32
reader for the same kind of value, so custom extension types with a
high OID would come back negative in ParameterDescriptionMessage.dataTypeIDs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant