On Thu, 23 Jan 2025 at 14:30, Aleksander Alekseev <aleksan...@timescale.com> wrote: > > Hi Peter, > > > These casts appear to use a particular endianness, but they don't > > document which one, and there is no explanation anywhere why that one is > > the right one. > > Right, I choose network order / big-endian. I agree that it would make > sense to emphasise this fact in the documentation below the examples. > Unfortunately I have no good reason for this particular design choice > other than "well this is how it is custom to represent numbers in a > consistent manner between different platforms but other than that the > choice was rather arbitrary". Should I just rephrase it a bit and add > to the documentation? >
IMO big-endian is the most convenient byte-ordering to use here, because then the string representation of the bytea is consistent with the hex representation of the integer. It's also consistent with the integer-to-bit casts, which output the most significant bits first, starting with the sign bit. As far as the docs go, it's important to document precisely what format is used, but I don't think it needs to explain why that choice was made. It should also mention the size of the result and that it's the two's complement representation, since there are other possible representations of integers. So I think it would be sufficient for the initial paragraph to say something like "Casting an integer to a bytea produces 2, 4, or 8 bytes, depending on the width of the integer type. The result is the two's complement representation of the integer, with the most significant byte first.", and then list the examples to demonstrate that. Regards, Dean
