Re: More work on SortSupport for text - strcoll() and strxfrm() caching

On Fri, Oct 9, 2015 at 11:44 AM, Robert Haas <robertmhaas(at)gmail(dot)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