Re: BUG #18196: Databases Created in Turkish Language Will Not Run on the Latest Version of Windows
От | Daniel Verite |
---|---|
Тема | Re: BUG #18196: Databases Created in Turkish Language Will Not Run on the Latest Version of Windows |
Дата | |
Msg-id | 48b32b36-1356-43f4-919b-a70dee481304@manitou-mail.org обсуждение исходный текст |
Ответ на | BUG #18196: Databases Created in Turkish Language Will Not Run on the Latest Version of Windows (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18196: Databases Created in Turkish Language Will Not Run on the Latest Version of Windows
|
Список | pgsql-bugs |
PG Bug reporting form wrote: > As a result, Turkish_Turkey.1254 is no longer present in the > operating system. Instead of Turkish_Turkey.1254, the Windows system > now uses Turkish_Türkiye.1254. > Databases created with Turkish_Turkey.1254 cannot find the > corresponding locale, resulting in errors and service disruptions Aside from the disappearance of the previous name, this "ü" in the new name also looks troublesome. It might be encoded as a single byte in an encoding of the ISO-8859-* family, in which case the byte would be 0xFC it seems, but in an UTF-8 context, it would be represented by the sequence 0xC3 0xBC. This locale name ends up in pg_database.datcollate and datctype, and since pg_database is shared among all databases of the instance, it's supposed to be encoded in a way that is compatible with all possible db encodings, which in fact implies not having characters outside of the US-ASCII character set. In practice, in a cluster initialized with the locale "Turkish_Türkiye.1254" and a monobyte encoding, assuming that an UTF-8 database can be successfully created in it , how would "select * from pg_database" from inside that database not fail with an UTF-8 decoding error? Best regards, -- Daniel Vérité https://postgresql.verite.pro/ Twitter: @DanielVerite
В списке pgsql-bugs по дате отправления: