On Thu, Oct 8, 2015 at 8:20 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I should point out that I did not call the macro DatumToBigEndian(),
> because it's actually the other way around. I called it
> DatumToLittleEndian(), since the unsigned integer comparator would
> work correctly on big-endian systems without calling any new macro
> (which is of course why the new macro does nothing on big-endian
> systems). We start off with a big endian Datum/unsigned integer on all
> platforms, and then we byteswap it to make it a little-endian unsigned
> integer if and when that's required (i.e. only on little-endian
> systems).
Hmm. But then this doesn't seem to make much sense:
+ * Rearrange the bytes of a Datum into little-endian order from big-endian
+ * order. On big-endian machines, this does nothing at all.
Rearranging bytes into little-endian order ought to be a no-op on a
little-endian machine; and rearranging them into big-endian order
ought to be a no-op on a big-endian machine.
Thinking about this a bit more, it seems like the situation we're in
here is that the input datum is always going to be big-endian.
Regardless of what the machine's integer format is, the sortsupport
abbreviator is going to output a Datum where the most significant byte
is the first one stored in the datum. We want to convert that Datum
to one that has *native* endianness. So maybe we should call this
DatumBigEndianToNative or something like that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
