From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(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:44:11 |
Message-ID: | CA+TgmoYgemQT6GSVST9G-=mh2Nnu2e2saovSOy=Ow=4C-fumHA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 8, 2015 at 8:20 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> I should point out that I did not call the macro DatumToBigEndian(),
> because it's actually the other way around. I called it
> DatumToLittleEndian(), since the unsigned integer comparator would
> work correctly on big-endian systems without calling any new macro
> (which is of course why the new macro does nothing on big-endian
> systems). We start off with a big endian Datum/unsigned integer on all
> platforms, and then we byteswap it to make it a little-endian unsigned
> integer if and when that's required (i.e. only on little-endian
> systems).
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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-10-09 18:47:25 | Re: Process pg_hba.conf keywords as case-insensitive |
Previous Message | Jim Nasby | 2015-10-09 18:35:21 | Re: Less than ideal error reporting in pg_stat_statements |