Горната функция на Postgres за турски символ не връща очаквания резултат

Вашият проблем е 100% Windows. (Или по-скоро Microsoft Visual Studio, с който е създаден PostgreSQL, за да бъдем по-точни.)

За протокола, SQL UPPER завършва с извикване на Windows LCMapStringW (чрез towupper чрез str_toupper ) с почти всички правилни параметри (локал 1055 турски за UTF-8 -кодиран, Turkish_Turkey база данни),

но

времето за изпълнение на Visual Studio (towupper ) не задава LCMAP_LINGUISTIC_CASING бит в LCMapStringW dwMapFlags на . (Мога да потвърдя, че настройката върши работа.) Това не се счита за грешка в Microsoft; това е проектирано и вероятно никога няма да бъде "поправено" (о, радостите от наследството.)

Имате три изхода от това:

• внедрете решението за обвивка на @Sorrow (или напишете своя собствена заместваща функция (DLL).)
• изпълнете екземпляра на PostgreSQL на напр. Ubuntu който показва правилното поведение за тюркски локали (@Sorrow потвърди, че работи за него); това е може би най-простият и чист изход.
• въвеждане на поправен 32-битов MSVCR100.DLL във вашия PostgreSQL bin директория (но въпреки че UPPER и LOWER би работило, други неща като сортирането може да продължат да се провалят -- отново, на ниво Windows. YMMV.)

За пълнота (и носталгично забавление) САМО , ето процедурата за корекция на Windows система (но не забравяйте, че освен ако няма да управлявате този екземпляр на PostgreSQL от люлката до гроба, може да причините много мъка на вашия наследник(и); всеки път, когато внедрявате нова тестова или резервна система от ако вие или вашият приемник(и) ще трябва да запомните да приложите корекцията отново -- и ако да кажем, че един ден надстроите до PostgreSQL 10, което казва, че използва MSVCR120.DLL вместо MSVCR100.DLL , тогава ще трябва да опитате късмета си и с корекция на новата DLL.) На тестова система

• използвайте HxD за да отворите C:\WINDOWS\SYSTEM32\MSVCR100.DLL
• запазете DLL веднага със същото име под своя PostgreSQL bin директория (не се опитвайте да копирате файла с помощта на Explorer или командния ред, те може да копират 64-битовата версия)
• когато файлът все още е отворен в HxD, отидете на Търсене> Замяна , изберете Тип данни:шестнадесетични стойности , след това
  • потърсете...... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 00
  • заменете с... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 01
  • ...после още веднъж...
  • потърсете...... FC 51 6A 01 8D 4D 08 51 68 00 02 00 00 50 E8 E2
  • заменете с... FC 51 6A 01 8D 4D 08 51 68 00 02 00 01 50 E8 E2
• ... и запазете отново в PostgreSQL bin директория, след това рестартирайте PostgreSQL и изпълнете отново вашата заявка.
  • ако вашата заявка все още не работи (уверете се, че вашата база данни е UTF-8 кодирана с Turkish_Turkey и за двата LC_CTYPE и LC_COLLATE ) отворете postgres.exe в 32-bit Dependency Walker и се уверете, че показва, че зарежда MSVCR100.DLL от PostgreSQL bin директория.
  • ако всички функции функционират добре, копирайте коригирания DLL в производствения PostgreSQL bin директория и рестартирайте.

НО ЗАПОМНЕТЕ, в момента, в който преместите данните от системата Ubuntu или от системата Windows с корекция към система Windows без корекция, вие отново ще имате проблема и може да не успеете да импортирате тези данни обратно в Ubuntu, ако екземплярът на Windows въведе дубликати в citext поле или в UPPER /LOWER базиран на функция индекс.