Górna funkcja Postgresa na tureckich znakach nie zwraca oczekiwanego wyniku

Twój problem jest 100% Windows. (A dokładniej Microsoft Visual Studio, z którym został zbudowany PostgreSQL.)

Dla rekordu SQL UPPER kończy się wywołaniem systemu Windows LCMapStringW (przez towupper przez str_toupper ) z prawie wszystkie właściwe parametry (lokalizacja 1055 turecki dla UTF-8 -encoded, Turkish_Turkey baza danych),

ale

środowisko uruchomieniowe Visual Studio (towupper ) nie ustawia LCMAP_LINGUISTIC_CASING bit w LCMapStringW dwMapFlags . (Mogę potwierdzić, że ustawienie to załatwia sprawę.) Nie jest to uważane za błąd w firmie Microsoft; jest to zgodne z projektem i prawdopodobnie nigdy nie zostanie „naprawione” (o radości spuścizny.)

Masz trzy wyjścia:

• zaimplementuj rozwiązanie opakowujące @Sorrow (lub napisz własną natywną funkcję zastępującą (DLL).)
• uruchom swoją instancję PostgreSQL na np. Ubuntu który wykazuje właściwe zachowanie dla tureckich lokalizacji (@Sorrow potwierdził, że to działa dla niego); jest to prawdopodobnie najprostsze i najczystsze wyjście.
• upuść załatany 32-bitowy plik MSVCR100.DLL w twoim bin PostgreSQL katalog (ale chociaż UPPER i LOWER zadziała, inne rzeczy, takie jak sortowanie, mogą nadal zawodzić – znowu na poziomie Windows. MMW.)

Dla kompletności (i nostalgiczna zabawa) TYLKO , oto procedura łatania systemu Windows (ale pamiętaj, że jeśli nie będziesz zarządzać tą instancją PostgreSQL od podstawki do grobu, możesz sprawić wiele żalu swoim następcom; za każdym razem, gdy wdrażasz nowy system testowy lub zapasowy z Ty lub Twoi następcy musielibyście pamiętać o ponownym zastosowaniu łatki - a jeśli powiedzmy, że pewnego dnia zaktualizujesz PostgreSQL 10, który, powiedzmy, używa MSVCR120.DLL zamiast MSVCR100.DLL , będziesz musiał spróbować szczęścia z zainstalowaniem poprawki do nowej biblioteki DLL). W systemie testowym

• użyj HxD aby otworzyć C:\WINDOWS\SYSTEM32\MSVCR100.DLL
• zapisz DLL od razu pod tą samą nazwą pod sobą PostgreSQL bin katalogu (nie próbuj kopiować pliku za pomocą Eksploratora lub wiersza poleceń, mogą skopiować wersję 64-bitową)
• Mając plik nadal otwarty w HxD, przejdź do Wyszukaj> Zastąp , wybierz Typ danych:wartości szesnastkowe , to
  • szukaj...... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 00
  • zamień na... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 01
  • ...potem jeszcze raz...
  • szukaj...... FC 51 6A 01 8D 4D 08 51 68 00 02 00 00 50 E8 E2
  • wymień na... FC 51 6A 01 8D 4D 08 51 68 00 02 00 01 50 E8 E2
• ...i ponownie zapisz w bin PostgreSQL katalogu, a następnie uruchom ponownie PostgreSQL i ponownie uruchom zapytanie.
  • jeśli zapytanie nadal nie działa (upewnij się, że Twoja baza danych jest zakodowana w UTF-8 za pomocą Turkish_Turkey dla obu LC_CTYPE i LC_COLLATE ) otwórz postgres.exe w 32-bitowym Dependency Walker i upewnij się, że wskazuje, że ładuje MSVCR100.DLL z bin PostgreSQLa katalog.
  • jeśli wszystkie funkcje dobrze skopiuj poprawioną bibliotekę DLL do produkcyjnego bin PostgreSQLa katalogu i uruchom ponownie.

ALE PAMIĘTAJ, że w momencie przeniesienia danych z systemu Ubuntu lub z załatanego systemu Windows do niezałatanego systemu Windows ponownie pojawi się problem i możesz nie być w stanie zaimportować tych danych z powrotem do Ubuntu, jeśli instancja Windows wprowadziła duplikaty w citext pole lub w UPPER /LOWER indeks funkcji na podstawie.