I think correct behavior will be get the whole locale from postgresql.conf (like the backend processes do) or from
environment.It’s a question, may be, from what place do take locale, but obviously from only one. But do not take
LC_TYPEfrom the one place (postgresql.conf), while LC_MESSAGES from other (environment). Te bug is here.
> 18 окт. 2018 г., в 19:29, Tom Lane <tgl@sss.pgh.pa.us> написал(а):
>
> =?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
