Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote:

> 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

Testing this briefly I noticed two regressions

1) all pg_collation.collversion are empty due to a trivial bug in 0002:

@ -1650,6 +1686,10 @@ get_collation_actual_version(char collprovider, const
char *collcollate)
{
char *collversion = NULL;

+ if (pg_strcasecmp("C", collcollate) ||
+ pg_strcasecmp("POSIX", collcollate))
+ return NULL;
+

This should be pg_strcasecmp(...) == 0

2) The following works with HEAD (default provider=icu) but errors out with
the patches:

postgres=# create database lat9 locale 'fr_FR(at)euro' encoding LATIN9 template
'template0';
ERROR: could not convert locale name "fr_FR(at)euro" to language tag:
U_ILLEGAL_ARGUMENT_ERROR

fr_FR(at)euro is a libc locale name

$ locale -a|grep fr_FR
fr_FR
fr_FR(at)euro
fr_FR.iso88591
fr_FR(dot)iso885915(at)euro
fr_FR.utf8

I understand that fr_FR(at)euro is taken as an ICU locale name, with the idea
that the locale
syntax being more or less compatible between both providers, this should work
smoothly. 0003 seems to go further in the interpretation and fail on it.
TBH the assumption that it's OK to feed libc locale names to ICU feels quite
uncomfortable.

Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite