On Sat, 2023-02-04 at 14:41 +0100, Daniel Verite wrote:
> Laurenz Albe wrote:
>
> > Cool so far. Now I created a database with that locale:
> >
> > CREATE DATABASE teutsch LOCALE_PROVIDER icu ICU_LOCALE german_phone
> > LOCALE "de_AT.utf8" TEMPLATE template0;
> >
> > Now the rules are not in "pg_database":
>
> The parameter after ICU_LOCALE is passed directly to ICU as a locale
> ID, as opposed to refering a collation name in the current database.
> This CREATE DATABASE doesn't fail because ICU accepts pretty much
> anything as a locale ID, ignoring what it can't parse instead of
> erroring out.
>
> I think the way to express what you want should be:
>
> CREATE DATABASE teutsch
> LOCALE_PROVIDER icu
> ICU_LOCALE 'de_AT'
> LOCALE 'de_AT.utf8'
> ICU_RULES '&a < g';
>
> However it still leaves "daticurules" empty in the destination db,
> because of an actual bug in the current patch.
I see. Thanks for the explanation.
> > I guess that it is not the fault of this patch that the collation
> > isn't there, but I think it is surprising. What good is a database
> > collation that does not exist in the database?
>
> Even if the above invocation of CREATE DATABASE worked as you
> intuitively expected, by getting the characteristics from the
> user-defined collation for the destination db, it still wouldn't work to
> refer
> to COLLATE "german_phone" in the destination database.
> That's because there would be no "german_phone" entry in the
> pg_collation of the destination db, as it's cloned from the template
> db, which has no reason to have this collation.
That makes sense. Then I think that the current behavior is buggy:
You should not be allowed to specify a collation that does not exist in
the template database. Otherwise you end up with something weird.
This is not the fault of this patch though.
Yours,
Laurenz Albe
