Re: BUG: Incorrect working with POSIX locale if database in UTF-8 encoding - Mailing list pgsql-general

From Tom Lane
Subject Re: BUG: Incorrect working with POSIX locale if database in UTF-8 encoding
Date
Msg-id 29517.1539880173@sss.pgh.pa.us
Whole thread Raw
In response to BUG: Incorrect working with POSIX locale if database in UTF-8encoding  (Олег Самойлов <splarv@ya.ru>)
Responses Re: BUG: Incorrect working with POSIX locale if database in UTF-8encoding  (Олег Самойлов <splarv@ya.ru>)
List pgsql-general
=?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <splarv@ya.ru> writes:
> [ postmaster's localized messages are printed as garbage if LANG is C or unset ]

I'm not quite convinced that this is a bug.  The reason it's misbehaving
is that in the postmaster process (and, probably, non-backend children)
LC_MESSAGES gets set to whatever you said in postgresql.conf, but LC_CTYPE
is never changed away from what it was in the postmaster's environment.
So if the prevailing environment setting is C/POSIX, gettext() throws up
its hands and substitutes "?" for non-ASCII characters, because it has
no idea which encoding to render them in.

This is sort of intentional, in that the environment LC_CTYPE ought to
reflect the "console encoding" that you're operating in; if you run your
terminal in say KOI8R, then you set LC_CTYPE=ru_RU.koi8r and messages
should get printed in the encoding the terminal is expecting.

We could maybe make a case for forcing gettext to use the encoding
implied by LC_MESSAGES if LC_CTYPE is C/POSIX, but I'm not really
convinced that there's anything principled about that.

On the other hand, the current behavior in this situation surely
isn't useful to anybody.  Arguably, gettext() is being pretty
unhelpful here, but I doubt we could get them to change.

Peter, any thoughts?

            regards, tom lane


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: convert real to numeric.
Next
From: Valery Sizov
Date:
Subject: query replication status when WAL-E is used