Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbnNf-0003Ig-Es for pgsql-committers@arkaria.postgresql.org; Mon, 13 Mar 2023 18:58:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pbnNe-00068o-BK for pgsql-committers@arkaria.postgresql.org; Mon, 13 Mar 2023 18:58:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbnNe-00068f-42 for pgsql-committers@lists.postgresql.org; Mon, 13 Mar 2023 18:58:46 +0000 Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbnNb-0002HA-4k for pgsql-committers@lists.postgresql.org; Mon, 13 Mar 2023 18:58:45 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id 5B5061C0002; Mon, 13 Mar 2023 18:58:35 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------9Ot865bMBglpgJnOTO0eBzMx" Message-ID: Date: Mon, 13 Mar 2023 14:58:34 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: pgsql: Add standard collation UNICODE Content-Language: en-US To: Thomas Munro , Tom Lane Cc: Jeff Davis , Peter Eisentraut , pgsql-committers@lists.postgresql.org References: <582e43d0a814e09c62ea662dd851f43bfc137a16.camel@j-davis.com> <231acf388c37597a9f0f8a3af9a899df99c28e1d.camel@j-davis.com> <1253026.1678567661@sss.pgh.pa.us> <98810acf-c2ea-ed90-2b5f-c8cfa6c1654f@dunslane.net> <1605453.1678651802@sss.pgh.pa.us> From: Andrew Dunstan In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------9Ot865bMBglpgJnOTO0eBzMx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2023-03-12 Su 18:47, Thomas Munro wrote: > On Mon, Mar 13, 2023 at 9:10 AM Tom Lane wrote: >> Andrew Dunstan writes: >>> On 2023-03-11 Sa 15:47, Tom Lane wrote: >>>> In general, I see no good reason for our regression tests to be making >>>> assumptions about exactly how ICU's root locale behaves, so I'd suggest >>>> just lobotomizing this test case so it doesn't depend on upper/lower >>>> sort order. >>> Yeah, I think we've found enough cases in old still not dead distros to >>> make this reasonable. >> I see topminnow is showing the symptom too, so it's now pretty clear >> that this was once a common behavior. I dug in ICU's release notes >> and couldn't find anything about it, but they must've changed something >> somewhen. > Most odd, and a bit worrying for the multi-lib concept we were > discussing (now for 17), though not fatal if it's something like > "there was one historical screwup back in 50.whatever, but now we are > more careful", or "it was a packaging error that was fixed but old > systems that aren't getting updated don't have the fix", so not even > ICU's fault (which would fit with Jeff's observation that he can't > repro the issue by building from ICU source at the 50.2 tag, as if > what is in the package is not what was tagged?!). It'd be nice to > understand what happened here... What do these disagreeing systems > report for the various version meta-data (Unicode version, CLDR > version, the opaque collator version, etc)? How would I discover that? Or if it's quicker I can give you access to one or two machines which exhibit the issue. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com --------------9Ot865bMBglpgJnOTO0eBzMx Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 2023-03-12 Su 18:47, Thomas Munro wrote:
On Mon, Mar 13, 2023 at 9:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 2023-03-11 Sa 15:47, Tom Lane wrote:

In general, I see no good reason for our regression tests to be making
assumptions about exactly how ICU's root locale behaves, so I'd suggest
just lobotomizing this test case so it doesn't depend on upper/lower
sort order.


        

          
Yeah, I think we've found enough cases in old still not dead distros to
make this reasonable.


        

        
I see topminnow is showing the symptom too, so it's now pretty clear
that this was once a common behavior.  I dug in ICU's release notes
and couldn't find anything about it, but they must've changed something
somewhen.


      

      
Most odd, and a bit worrying for the multi-lib concept we were
discussing (now for 17), though not fatal if it's something like
"there was one historical screwup back in 50.whatever, but now we are
more careful", or "it was a packaging error that was fixed but old
systems that aren't getting updated don't have the fix", so not even
ICU's fault (which would fit with Jeff's observation that he can't
repro the issue by building from ICU source at the 50.2 tag, as if
what is in the package is not what was tagged?!).  It'd be nice to
understand what happened here...  What do these disagreeing systems
report for the various version meta-data (Unicode version, CLDR
version, the opaque collator version, etc)?

    

    


    

    
How would I discover that? Or if it's quicker I can give you
      access to one or two machines which exhibit the issue.

    


    

    
cheers

    


    

    
andrew
    

    
--
Andrew Dunstan
EDB: https://www.enterprisedb.com


  


--------------9Ot865bMBglpgJnOTO0eBzMx--