On Tue, Dec 10, 2024 at 11:57:07AM +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/17/protocol-message-formats.html > Description: > > I don't see it clearly stated which Int fields are signed and which are > unsigned. If it can be assumed that Int is signed and Byte is unsigned then > the object id fields are wrong because they should be unsigned.
(Thead moved to hackers since it involves internals issues.) This is a very good point. I looked at the backend code and couldn't find a clear answer. For example, let's look at AuthenticationOk, which uses src/backend/libpq/auth.c::sendAuthRequest(). You have "AuthRequest" passed in as an unsigned int32, stored in StringInfoData.cursor as a signed int32, passed to pq_sendint32() as a signed int32, which gets passed to pq_writeint32(), which casts it back to a unsigned int32 to send on the socket. For the length of AuthenticationOk, it uses StringInfo.len, which is a signed int32, but that is cast by /pgtop/src/backend/libpq/pqcomm.c::socket_putmessage() to unsigned int32 in () before sending it on the socket. Why is StringInfo.len a signed int? Do we need to use -1 in that field? Do we not expect that to exceed 2GB? A related issue is that the format our docs use for this is confusing. Is Byte1 signed or unsigned. Can we assume Int32 is signed since it is in C? (In C, the sign of "char" is undetermined.) We display the data type and value as "Int32(8)", which looks more like a function call than what is represents. Any ideas on how to improvem that? -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
