On Fri, Oct 9, 2015 at 2:48 PM, Peter Geoghegan <p...@heroku.com> wrote: > 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.
OK, committed that way. -- 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
