トルコ文字のPostgres上位関数が期待される結果を返さない

あなたの問題は 100％Windows。 （正確には、PostgreSQLが構築されたMicrosoft Visual Studioです。）

記録として、SQL UPPER 最終的にWindowsの LCMapStringWを呼び出すことになります。（ towupper経由 str_toupper ）ほぼすべての適切なパラメータ（UTF-8のロケール1055トルコ語 -エンコードされたTurkish_Turkey データベース）、

しかし

Visual Studioランタイム（towupper ） LCMAP_LINGUISTIC_CASINGを設定しません LCMapStringWのビットのdwMapFlags 。（設定することでうまくいくことを確認できます。）これはMicrosoftのバグとは見なされません。これは仕様によるものであり、おそらく「修正」されることはありません （ああ、レガシーの喜びです。）

これには3つの方法があります：

@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を開きます
PostgreSQL binの下に同じ名前でDLLをすぐに保存しますディレクトリ（エクスプローラーまたはコマンドラインを使用してファイルをコピーしようとしないでください。64ビットバージョンをコピーする可能性があります）
ファイルをHxDで開いたまま、検索>置換に移動します、データ型：16進値を選択します、次に
- 検索......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を再起動し、クエリを再実行します。
- それでもクエリが機能しない場合（データベースがTurkish_TurkeyでUTF-8エンコードされていることを確認してください両方のLC_CTYPE およびLC_COLLATE ）postgres.exeを開きます 32ビットのディペンデンシーウォーカー MSVCR100.DLLが読み込まれることを示していることを確認します PostgreSQLのbinからディレクトリ。
- すべての関数がパッチを適用したDLLを本番PostgreSQLのbinに適切にコピーする場合ディレクトリを作成して再起動します。

ただし、Ubuntuシステムまたはパッチが適用されたWindowsシステムからパッチが適用されていないWindowsシステムにデータを移動すると、再び問題が発生し、Windowsインスタンスがで重複を導入した場合、このデータをUbuntuにインポートして戻すことができない場合があります。 citext フィールドまたはUPPER / LOWER ベースの関数インデックス。