For example, 'i'::citext = 'İ'::citext fails to be true. It must now be using UTF-8 (unlike, say, Drongo) and non-C ctype, given that the test isn't skipped. This isn't the first time that we've noticed that Windows doesn't seem to know about İ→i (see [1]), but I don't think anyone has explained exactly why, yet. It could be that it just doesn't know about that in any locale, or that it is locale-dependent and would only do that for Turkish, the same reason we skip the test for ICU, or ...
Either way, it seems like we'll need to skip that test on Windows if we want hamerkop to be green. That can probably be cribbed from collate.windows.win1252.sql into contrib/citext/sql/citext_utf8.sql's prelude... I just don't know how to explain it in the comment 'cause I don't know why. One new development in Windows-land is that the system now does actually support UTF-8 in the runtime libraries[2]. You can set it at a system level, or for an application at build time, or by adding ".UTF-8" to a locale name when opening the locale (apparently much more like Unix systems, but I don't know what exactly it does). I wonder why we see this change now... did hamerkop have that ACP=UTF-8 setting applied on purpose, or if computers in Japan started doing that by default instead of using Shift-JIS, or if it only started picking UTF-8 around the time of the Meson change somehow, or the initdb-template change. It's a little hard to tell from the logs. [1] https://www.postgresql.org/message-id/CAC%2BAXB10p%2BmnJ6wrAEm6jb51%2B8%3DBfYzD%3Dw6ftHRbMjMuSFN3kQ%40mail.gmail.com [2] https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page