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

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More work on SortSupport for text - strcoll() and strxfrm() caching
Date: 2015-10-09 18:48:52
Message-ID: CAM3SWZSXc03c306Pt5xEXwEUrWOzynezqye8vvCiqfEy9KAw1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-10-09 18:52:57 Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files
Previous Message Robert Haas 2015-10-09 18:47:25 Re: Process pg_hba.conf keywords as case-insensitive