At Mon, 8 Aug 2016 10:19:10 +0300, Victor Wagner <vi...@wagner.pp.ru> wrote in <20160808101910.49bee...@fafnir.local.vm> > 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.
Agreed. > 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. Looking at check_client_encoding(), the comment says as following. | * If we are not within a transaction then PrepareClientEncoding will not | * be able to look up the necessary conversion procs. If we are still | * starting up, it will return "OK" anyway, and InitializeClientEncoding | * will fix things once initialization is far enough along. After We shold overcome this to realize startup-time check for conversion procs. > It is much more local change and is comparable by complexity with one, > proposed by Tom Lane. I'm not sure what messages may be raised before authentication but it can be a more generic-solution. (Adding check during on-session.) regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
