From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | vitus(at)wagner(dot)pp(dot)ru |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: handling unconvertible error messages |
Date: | 2016-08-08 08:18:21 |
Message-ID: | 20160808.171821.100221089.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Mon, 8 Aug 2016 10:19:10 +0300, Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> wrote in <20160808101910(dot)49beeed6(at)fafnir(dot)local(dot)vm>
> On Fri, 5 Aug 2016 11:21:44 -0400
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo Nagata | 2016-08-08 08:40:00 | per-statement-level INSTEAD OF triggers |
Previous Message | Vladimir Sitnikov | 2016-08-08 07:49:33 | Re: No longer possible to query catalogs for index capabilities? |