On 2 June 2017 at 03:18, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
> On Fri, Jun 2, 2017 at 9:27 AM, Peter Geoghegan <pg@bowt.ie> wrote:
>> On Thu, Jun 1, 2017 at 2:24 PM, Thomas Munro
>> <thomas.munro@enterprisedb.com> wrote:
>>> Why should ICU be any different than the system provider in this
>>> respect? In both cases, we have a two-level comparison: first we use
>>> the collation-aware comparison, and then as a tie breaker, we use a
>>> binary comparison. If we didn't do a binary comparison as a
>>> tie-breaker, wouldn't the result be logically incompatible with the =
>>> operator, which does a binary comparison?
Ok. I was thinking we are doing the tie-breaker because specifically
strcoll_l() was unexpectedly returning 0 for some cases. Now I get it,
that we do that to be compatible with texteq().
Secondly, I was also considering if ICU especially has a way to
customize an ICU locale by setting some attributes which dictate
comparison or sorting rules for a set of characters. I mean, if there
is such customized ICU locale defined in the system, and we use that
to create PG collation, I thought we might have to strictly follow
those rules without a tie-breaker, so as to be 100% conformant to ICU.
I can't come up with an example, or may there isn't one, but , say ,
there is a locale which is supposed to sort only by lowest comparison
strength (de@strength=1 ?? ). In that case, there might be many
characters considered equal, but PG < operator or > operator would
still return true for those chars.
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company
