Thread: Signed-ness of ints is unclear in FE-BE protocol docs
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/protocol-message-types.html Description: Hi, I'm the maintainer of Npgsql, the .NET open source driver for PostgreSQL. The protocol docs generally do not mention whether ints are signed or unsigned - this has actually bitten me once in the past, where a signed int was accidentally used to interpret an unsigned int coming from PostgreSQL, leading to issues. The ambiguity has made me resort to inspecting the PostgreSQL sources in order to be sure. First, I'd consider clarifying this on the "Message Data Types" page (https://www.postgresql.org/docs/current/protocol-message-types.html). 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. Thanks! Shay Shay
On 2020-06-09 23:35, PG Doc comments form wrote: > The protocol docs generally do not mention whether ints are signed or > unsigned - this has actually bitten me once in the past, where a signed int > was accidentally used to interpret an unsigned int coming from PostgreSQL, > leading to issues. The ambiguity has made me resort to inspecting the > PostgreSQL sources in order to be sure. > > First, I'd consider clarifying this on the "Message Data Types" page > (https://www.postgresql.org/docs/current/protocol-message-types.html). sure > 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. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> 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.
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?
- The starting point of the WAL data in this message, given in
- XLogRecPtr format.
+ The starting point of the WAL data in this message.
- XLogRecPtr format.
+ The starting point of the WAL data in this message.
but it was removed for an unknown reason.
--
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services