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:

Reply via email to