Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
От | MauMau |
---|---|
Тема | Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII |
Дата | |
Msg-id | D27EB9DC2C6E46BF9546A6C7B5B80891@maumau обсуждение исходный текст |
Ответ на | Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
|
Список | pgsql-hackers |
From: "Peter Eisentraut" <peter_e@gmx.net> > On 9/9/13 4:42 PM, MauMau wrote: > 1. Take the approach that doesn't use bind_textdomain_codeset("libc") >> (i.e. the second version of errno_str.patch) for 9.4 and older releases. >> >> 2. Use bind_textdomain_codeset("libc") (i.e. take >> strerror_codeset.patch) for 9.4, and take the >> non-bind_textdomain_codeset approach for older releases. > > I think we are not going to backpatch any of this. There is a clear > workaround: fix your locale settings. No, it's a hard workaround to take: 1. Recreate the database with LC_CTYPE = ja_JP.UTF-8. This changes various behaviors such as ORDER BY, index scan, and the performance of LIKE clause. This is almost impossible. 2. Change lc_messages in postgresql.conf to 'C'. This is OK for me as I can read/write English to some extent (though poor). But English is difficult for some (or many?) Japanese. So I hesitate to ask the users to do so. Regards MauMau
В списке pgsql-hackers по дате отправления: