Well this should be fun ... "Beware of your next glibc upgrade"
postgresql.verite.pro/blog/2018/08/2
Conversation
We need ICU collations that are usable as DB/cluster default.
Behavior of glibc collations is explicitly allowed to change. There is no mechanism in place to detect incompatibility. *Every* glibc upgrade should be assumed unsafe.
2
1
3
What do you think about the idea of a system_collation_version_command GUC, and a set of shell scripts for common operating systems?
1
Meh. There is some versioning info in glibc, actually, but it uses a non-standard interface, and might not be any good. I'd rather deal with the problem once, comprehensively. We should be able to certify compatibility of on-disk format with easy-to-use tool.
I don't buy the argument that OS is intrinsically best place for collations. Users have a bunch of vendored ICUs without even realizing it, or use different collations on client and server side.
1
Yeah. I have mixed feelings about that TBH. I don't really want a proliferation of disagreeing copies of tzinfo hiding in my software stack, and likewise for this stuff.
1
1
Show replies
I wasn't thinking of trusting glibc or any other libc BTW, I was thinking of a nuclear option like "tar c /usr/share/locale | md5" or whatever. Of course I agree with you 100% about making ICU available as a default.
3