Re: Signed-ness of ints is unclear in FE-BE protocol docs

On Thu, 11 Jun 2020 at 15:07, Shay Rojansky <roji(at)roji(dot)org> wrote:

>
> > Second, across the protocol docs, rather than using Int32 and Int64,
>> which
>> > generally look like they're signed (depending on which language you're
>> > coming from), I'd consider using UInt32/UInt64, which are unambiguous
>> with
>> > regards to signed-ness.
>>
>> Well, they are actually signed, so I'm confused why you think we should
>> change the documentation to unsigned.
>>
>
> Interesting... I'm not 100% sure, but I recently received a report that
> the WAL coordinates in XLogData (
> https://www.postgresql.org/docs/current/protocol-replication.html) are
> unsigned longs, is that a mistake? Are you saying all values in the
> protocol are always signed?
>

AFAICS, the definition is correct. Int64 means an 64-bit integer in network
byte order [1]. It does not mention signedness. All LSNs in the protocol
messages are advertised as Int64. A possible improvement is to inform that
that Int64 is a XLogRecPtr in each message block that contains LSN. It used
to be like that before the commit add6c3179a4d4fa3e62dd3e86a00f23303336bac

- The starting point of the WAL data in this message, given in
- XLogRecPtr format.
+ The starting point of the WAL data in this message.

but it was removed for an unknown reason.

[1] https://www.postgresql.org/docs/current/protocol-message-types.html

--
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services