Patch for bind message to clarify signedness of parameters and result column format codes
Currently we don't say whether the number of parameters is signed or
unsigned. Same with results
See attached patch.
Regards,
Dave Cramer
Attachments:
0001-doc-clarify-unsigned-integer-fields-in-protocol-messages.patchapplication/octet-stream; name=0001-doc-clarify-unsigned-integer-fields-in-protocol-messages.patchDownload+29-24
On 09.06.26 13:51, Dave Cramer wrote:
Currently we don't say whether the number of parameters is signed or
unsigned. Same with results
Instead of repeating this with every message, we should clarify this in
the section "Message Data Types".
I had always assumed that a type designation like Int16 or Int32 is
signed, because of how they look like C types. But on the other hand,
the POSIX functions to convert between host and network order only deal
with unsigned types. So it's not obvious either way.
On Wed, 10 Jun 2026 at 09:16, Peter Eisentraut <peter@eisentraut.org> wrote:
On 09.06.26 13:51, Dave Cramer wrote:
Currently we don't say whether the number of parameters is signed or
unsigned. Same with resultsInstead of repeating this with every message, we should clarify this in
the section "Message Data Types".
I've attached a new patch.
I had always assumed that a type designation like Int16 or Int32 is
signed, because of how they look like C types. But on the other hand,
the POSIX functions to convert between host and network order only deal
with unsigned types. So it's not obvious either way.It was surprising to me that some of them were unsigned
Dave