On Fri, Oct 9, 2015 at 2:48 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Oct 9, 2015 at 11:44 AM, Robert Haas <robertmhaas@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
