On Fri, 5 Aug 2016 11:21:44 -0400
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> On 8/4/16 2:45 AM, Victor Wagner wrote:
> > 4. At the session startup try to reinitializie LC_MESSAGES locale
> > category with the combination
> > of the server (or better client-send) language and region and
> > client-supplied encoding, and if this failed, use untranslated error
> > message. Obvoisly, attempt to set locale to ru_RU.ISO8859-1 would
> > fail. so, if client would ask server with ru_RU.UTF-8 default
> > locale to use LATIN1 encoding, server would fallback to
> > untranslated messages.
>
> I think this is basically my solution (1), with the same problems.
>
I think, that there is a big difference from server point of view.
You propose that both translated and untranslated message should be
passed around inside backend. It has some benefits, but requires
considerable reworking of server internals.
My solution doesn't require keeping both original message and
translated one during all call stack unwinding. It just checks if
combination of language and encoding is supported by the NLS subsystem,
and if not, falls back to untranslated message for entire session.
It is much more local change and is comparable by complexity with one,
proposed by Tom Lane.