On Fri, Oct 9, 2015 at 2:48 PM, Peter Geoghegan <[email protected]> wrote: > On Fri, Oct 9, 2015 at 11:44 AM, Robert Haas <[email protected]> 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.
OK, committed that way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
