Re: Order changes in PG16 since ICU introduction - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Order changes in PG16 since ICU introduction
Date
Msg-id 2aed8f5955ce1ab884ef3ee2adca0d65ac8e7218.camel@j-davis.com
Whole thread Raw
In response to Re: Order changes in PG16 since ICU introduction  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Order changes in PG16 since ICU introduction
List pgsql-hackers
On Fri, 2023-04-21 at 22:35 +0100, Andrew Gierth wrote:
> > > > >
> Can lc_collate_is_c() be taught to check whether an ICU locale is
> using
> POSIX collation?

Attached are a few small patches:

  0001: don't convert C to en-US-u-va-posix
  0002: handle locale C the same regardless of the provider, as you
suggest above
  0003: make LOCALE (or --locale) apply to everything including ICU

As far as I can tell, any libc locale has a reasonable match in ICU, so
setting LOCALE to either C or a libc locale name should be fine. Some
locales are only valid in ICU, e.g. '@colStrength=primary', or a
language tag representation, so if you do something like:

  create database foo locale 'en_US@colStrenghth=primary'
    template template0;

You'll get a decent error like:

  ERROR:  invalid LC_COLLATE locale name: "en_US@colStrenghth=primary"
  HINT:  If the locale name is specific to ICU, use ICU_LOCALE.

Overall, I think it works out nicely. Let me know if there are still
some confusing cases. I tried a few variations and this one seemed the
best, but I may have missed something.

Regards,
    Jeff Davis


Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: could not extend file "base/5/3501" with FileFallocate(): Interrupted system call
Next
From: Junwang Zhao
Date:
Subject: [pg_rewind] use the passing callback instead of global function