On Thu, 11 Jun 2020 at 15:07, Shay Rojansky <roji@roji.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.