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 <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
