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 19:11:39 |
Message-ID: | CA+Tgmob5YqN7HTx_pRuiCfdRHMBTcbLYO9=vjQgGyWsmdp7VWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 9, 2015 at 2:48 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> 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.
OK, committed that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-10-09 19:14:26 | Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::') |
Previous Message | Robert Haas | 2015-10-09 18:55:22 | Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files |