4 ms·
libicu is deliberately doing this because one of its purpose is to offer Unicode ordering. If consumers try the new ordering on non-rebuild objects, it could le
by braiamp 2y ago
libicu is deliberately doing this because one of its purpose is to offer Unicode ordering. If consumers try the new ordering on non-rebuild objects, it could lead to data loss. That's what happened with glibc 2.28. [0]
If postgres prefers explicit library versions to prevent data corruption, then icu is doing things correctly and making sure that downstream consumers don't shoot themselves in the foot.
[0]: https://wiki.postgresql.org/wiki/Locale_data_changes https://wiki.postgresql.org/wiki/Locale_data_changes
- cookiengineer 2y agoHonestly, the more I was researching about what happened in that glibc version update, the more I thought "self inflicted". If you're using NULL terminated strings everywhere, and not UTF8/16, it's your own fault for doing so. Especially if you are building a database which should always contain a length of bytes or at least a CRC check before each entry's contents in its serialized file format to prevent exactly this from happening. (Let alone the question why is there no schema version that should have prevented this from happening in the first place)