On Fri, 5 Aug 2016 11:21:44 -0400 Peter Eisentraut <peter.eisentr...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
