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_TYPE from the one place (postgresql.conf), while LC_MESSAGES from other (environment). Te bug is here. > 18 окт. 2018 г., в 19:29, Tom Lane <tgl@xxxxxxxxxxxxx> написал(а): > > =?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <splarv@xxxxx> 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
