On Wed, Oct 9, 2019 at 12:16 AM Marius Timmer <marius.tim...@uni-muenster.de> wrote: > like the others before me we (the university of Münster) are happy to > see this feature as well. Thank you this. > > When I applied the patch two weeks ago I run into the issue that initdb > did not recognize the new parameters (collation-provider and icu-locale) > but I guess it was caused by my own stupidity. > > > When trying databases defined with ICU locales, I see that backends > > that serve such databases seem to have their LC_CTYPE inherited from > > the environment (as opposed to a per-database fixed value). > I am able to recreate the issue described by Daniel on my machine. > > Now it works as expected. I just had to update the patch since commit > 3f6b3be3 had modified two lines which resulted in conflicts. You find > the updated patch as attachement to this mail.
I rebased this patch, and tweaked get_collation_action_version() very slightly so that you get collation version change detection (of the ersatz kind provided by commit d5ac14f9) for the default collation even when not using ICU. Please see attached. +struct pg_locale_struct global_locale; Why not "default_locale"? Where is the terminology "global" coming from? + Specifies the collation provider for the database. "for the database's default collation"?
v2-0001-Add-option-to-use-ICU-as-global-collation-provide.patch
Description: Binary data
