On Thu, Dec 12 2019, "f.holop" <min...@obiit.org> wrote: > Landry Breuil - Thu, 12 December 2019 at 08:51:49 >> On Thu, Dec 12, 2019 at 01:47:25AM +0100, Jeremie Courreges-Anglas wrote: >> > >> > +cc maintainer >> > >> > This has bugged me for some time, I think enabling ICU makes sense. >> > Here's a wip diff. I fear it might cause issues with existing >> > databases. Real world tests would probably help. >> >> I doubt it can have side effects on existing databases as they all have >> a locale (and potential collations) configured during initdb, and adding >> the possibility to use more locales/collations shouldnt affect existing >> ones. Of course, to be tested in the real world :) > > initdb just sets "default" collation/ctype for `template1`. when > collation/ctype needs to be different, `CREATE DATABASE` must use the > template `template0`. > > Collation cannot be changed on a database after it has been created as > it affects the index creation as well.
Can you actually use ICU as the default collation algorithm used by a database? Sadly using ICU doesn't seem to be the silver bullet I was hoping for. postgres on Linux distros still defaults to the libc collation backend. You can't just push a button so that ICU is used by default[0]. [0] https://www.postgresql.org/message-id/flat/3366.1498183854%40sss.pgh.pa.us#3366.1498183...@sss.pgh.pa.us So right now it seems that adding ICU might help a few users who can tweak their schemas for their specific needs. That's much less interesting than what I expected. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
