On Thu, Oct 8, 2015 at 8:20 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
