On Fri, Oct 9, 2015 at 11:44 AM, Robert Haas <robertmh...@gmail.com> wrote: > 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.
I think that that's very clearly implied anyway. > 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. I'd be fine with DatumBigEndianToNative() -- I agree that that's slightly better. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
