On Tue, 2023-03-14 at 08:48 -0700, Jeff Davis wrote:
> Actually, now that I think about it, we could just search all known
> locales using either ucol_getAvailable() or uloc_getAvailable(), and
> see if there's a match. Not very clean, but it should catch most
> problems. I'll look into whether the
On Mon, 2023-03-13 at 18:13 -0700, Andres Freund wrote:
> What non-error code is returned in the above example?
When the collator for locale "asdf" is opened, the status is set to
U_USING_DEFAULT_WARNING.
That seemed very promising at first, but it's the same thing returned
after opening most val
On 14.03.23 01:26, Tom Lane wrote:
Unless someone has a better idea, I think we need to bump the minimum
required ICU version to 55. That would solve the issue in v16 and
later, but those using old versions of ICU and old versions of postgres
would still be vulnerable to these kinds of typos.
..
Hi,
On 2023-03-13 16:39:04 -0700, Jeff Davis wrote:
> In ICU 54 and earlier, if ucol_open() is unable to find a matching
> locale, it will fall back to the *environment*.
>
> Using ICU 54:
>
> initdb -D data -N --locale="en_US.UTF-8"
> pg_ctl -D data -l logfile start
> psql postgres -c "cr
Jeff Davis writes:
> In ICU 54 and earlier, if ucol_open() is unable to find a matching
> locale, it will fall back to the *environment*.
That's not great, but ...
> Unless someone has a better idea, I think we need to bump the minimum
> required ICU version to 55. That would solve the issue in
In ICU 54 and earlier, if ucol_open() is unable to find a matching
locale, it will fall back to the *environment*.
Using ICU 54:
initdb -D data -N --locale="en_US.UTF-8"
pg_ctl -D data -l logfile start
psql postgres -c "create collation asdf(provider=icu, locale='asdf')"
# returns true
