On Mon, 08 Aug 2016 18:11:54 +0900 (Tokyo Standard Time) Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Mon, 08 Aug 2016 17:18:21 +0900 (Tokyo Standard Time), Kyotaro > HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in > <20160808.171821.100221089.horiguchi.kyot...@lab.ntt.co.jp> > > Somewhat wrong. The core problem is the procedures offered by > PrepareClientEncoding is choosed only by encoding->encoding > basis, not counting character set compatibility. So, currently > this is not detectable before actually doing conversion of a > character stream. Yes, my idea was to check language/encoding compatibility. Make sure that NLS messages can be represented in the client-specified encoding in a readable way. As far, as I know, there is no platform-independent bulletproof way to do so. On Unix you can try to initialize locale with given language and given encoding, but it can fail even if encoding is compatible with language, simply because corresponding locale is not generated on this system. But this seems to be a problem of system administration and can be left out to local sysadmins. Once you have correctly initialized LC_MESSAGES, you don't need encoding conversion routines for the NLS messages. You can use bind_textdomain_codeset function to provide messages in the client-desired encoding. (but this can cause problems with server logs, where messages from different sessions would come in different encodings) On Windows things are more complicated. There is just one ANSI code page, associated to given language, and locale initialization would fail with any other codepage, including utf-8. > regards, > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
