Hàm trên Postgres trên ký tự tiếng Thổ Nhĩ Kỳ không trả về kết quả mong đợi

Vấn đề của bạn là 100% Windows. (Hay đúng hơn là Microsoft Visual Studio, mà PostgreSQL được xây dựng bằng, nói chính xác hơn.)

Đối với bản ghi, SQL UPPER kết thúc bằng cách gọi LCMapStringW của Windows ' (qua towupper qua str_toupper ) với gần như tất cả các thông số phù hợp (ngôn ngữ 1055 tiếng Thổ Nhĩ Kỳ cho UTF-8 -encoded, Turkish_Turkey cơ sở dữ liệu),

nhưng

Visual Studio Runtime (towupper ) không đặt LCMAP_LINGUISTIC_CASING bit trong LCMapStringW của dwMapFlags . (Tôi có thể xác nhận rằng cài đặt nó thực hiện thủ thuật.) Đây không được coi là một lỗi tại Microsoft; nó là do thiết kế và có thể sẽ không bao giờ được "sửa" (ôi những niềm vui của di sản.)

Bạn có ba cách để thoát khỏi điều này:

triển khai giải pháp trình bao bọc của @ Sorrow (hoặc viết chức năng thay thế hàm gốc (DLL) của riêng bạn.)
chạy phiên bản PostgreSQL của bạn trên v.d. Ubuntu thể hiện hành vi phù hợp với ngôn ngữ Thổ Nhĩ Kỳ (@Sorrow xác nhận rằng nó phù hợp với anh ta); đây có lẽ là cách đơn giản và sạch sẽ nhất.
giảm MSVCR100.DLL 32 bit được vá trong bin PostgreSQL của bạn thư mục (nhưng mặc dù UPPER và LOWER sẽ hoạt động, những thứ khác như đối chiếu có thể tiếp tục không thành công - một lần nữa, ở cấp Windows. YMMV.)

Để có sự hoàn chỉnh (và niềm vui hoài cổ) CHỈ , đây là thủ tục để vá hệ thống Windows (nhưng hãy nhớ rằng, trừ khi bạn đang quản lý phiên bản PostgreSQL này từ cái nôi này sang cái khác, bạn có thể gây ra rất nhiều đau buồn cho (các) người kế nhiệm của bạn; bất cứ khi nào triển khai một hệ thống thử nghiệm hoặc sao lưu mới từ bạn hoặc (những) người kế nhiệm của bạn sẽ phải nhớ áp dụng lại bản vá - và nếu giả sử một ngày nào đó bạn nâng cấp lên PostgreSQL 10, tức là sử dụng MSVCR120.DLL thay vì MSVCR100.DLL , thì bạn cũng sẽ phải thử vận may của mình bằng cách vá DLL mới.) Trên hệ thống thử nghiệm

sử dụng HxD để mở C:\WINDOWS\SYSTEM32\MSVCR100.DLL
lưu DLL ngay lập tức với cùng tên trong PostgreSQL bin của bạn thư mục (không cố sao chép tệp bằng Explorer hoặc dòng lệnh, họ có thể sao chép phiên bản 64bit)
với tệp vẫn đang mở trong HxD, đi tới Tìm kiếm> Thay thế , chọn Datatype:Hexvalues  , sau đó
- tìm kiếm ...... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 00
- thay thế bằng ... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 01
- ... sau đó một lần nữa ...
- tìm kiếm ...... FC 51 6A 01 8D 4D 08 51 68 00 02 00 00 50 E8 E2
- thay thế bằng ... FC 51 6A 01 8D 4D 08 51 68 00 02 00 01 50 E8 E2
... và lưu lại trong bin của PostgreSQL thư mục, sau đó khởi động lại PostgreSQL và chạy lại truy vấn của bạn.
- nếu truy vấn của bạn vẫn không hoạt động (đảm bảo cơ sở dữ liệu của bạn được mã hóa UTF-8 bằng Turkish_Turkey cho cả LC_CTYPE và LC_COLLATE ) mở postgres.exe trong Người phụ thuộc 32-bit và đảm bảo rằng nó cho biết nó đang tải MSVCR100.DLL từ bin của PostgreSQL thư mục.
- nếu tất cả các chức năng đều sao chép tốt tệp DLL đã vá vào bin sản xuất PostgreSQL thư mục và khởi động lại.

NHƯNG HÃY NHỚ, thời điểm bạn di chuyển dữ liệu khỏi hệ thống Ubuntu hoặc từ hệ thống Windows đã vá lỗi sang hệ thống Windows chưa được vá lỗi, bạn sẽ gặp sự cố một lần nữa và bạn có thể không thể nhập dữ liệu này trở lại trên Ubuntu nếu phiên bản Windows được giới thiệu trùng lặp trong một citext trường hoặc trong một UPPER / LOWER chỉ số chức năng dựa trên cơ sở.