Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: James Inform <james(dot)inform(at)pharmapp(dot)de>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Euler Taveira <euler(at)eulerto(dot)com>
Subject: Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation
Date: 2022-08-14 06:31:06
Message-ID: CAH2-Wzmqrjqv9pgyzebgnqmcac1Ct+UxG3VQU7kSVUNDf_yF2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Aug 13, 2022 at 11:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> says that only the "if (sss->collate_c)" path in varstr_abbrev_convert
> gets exercised in our regression tests. I thought maybe that just
> meant that the coverage.postgresql.org run uses C locale, but I see
> the same lack-of-coverage in a local test under LANG=en_US.utf8.
> How can we only be reaching this function with sss->collate_c true
> when the prevailing locale isn't that?

We don't trust libc's strxfrm() following the debacle with
locale-aware abbreviated keys back in 2016 (unless the user builds
their own Postgres, and goes out of their way to #define
TRUST_STRXFRM). So the relevant strxfrm() code is arguably dead code.

ICU is different: our policy with ICU locales has always been to trust
ICU's strxfrm()-like function to agree with ICU's strcoll()-like
function.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Noah Misch 2022-08-14 07:00:53 Re: COPY TO CSV produces data that is incompatible/unsafe for \COPY FROM CSV
Previous Message Tom Lane 2022-08-14 06:15:45 Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation