> (Maybe database clusters should have a header that wouldn’t allow > incompatible server versions to process the existing data. I wonder if it > would take more than 8 bytes per server. But I guess it was not know to be > incompatible. Even my two CIs didn’t show it.)
I had some thoughts along those lines too[3]. I thought about checksumming libc and all relevant collation files (ie OS specific files) so you could notice when anything that could bite you changes (that is just some sketched out ideas, not production code). Some have suggested that PostgreSQL should stop using OS collations and adopt ICU[4] and then use its versioning metadata. Of course some people already use ICU on FreeBSD because the old strcoll implementation didn't play well with Unicode, but those users are still presumably exposed to silent corruption when ICU changes because AFAIK that didn't keep track of ICU versions.
I have been using PostgreSQL for 12 years. *Every* issue that I personally ever had was locale-related.
I define "issue" as not totally my fault and it took more than a hour to fix. That’s why I was a bit sarcastic with my comments about the year 2016. In the 80’s I have grown up on sci-fi movies about spaceships make wormholes to travel to the unknown parts of the Universe, even capable of shifting dimensions, but today, one of the biggest issue in IT is when one wants to use UTF-8.
I think I spent more time on fixing locale related issues than on fixing all the rest together.
(Not counting the bugs in my own code.)
Once I tried DragonflyBSD. It could not compile ICU so I deleted it.
I used to run PostgreSQL with ICU on FreeBSD, but I switched from ports to binary packages. Mixing them isn’t fun. (Well, currently I have it mixed.) Anyway, ICU is turned on for PostgreSQL 9.6 even in the pkg version. Hurray.
