On Wednesday 31 December 2008 20:23:47 Tom Lane wrote:
> > The proper fix is probably to include the client encoding in the
> > connection startup message.
>
> What of errors occurring before such an option could be applied?
Connection errors are handled by the client, which knows the client encoding.
If the setting of the client encoding would be one of the first things to be
done on the server side, you would only have a handful of possible error
conditions left (e.g., setlocale failed, out of memory). You could choose to
report those in plain ASCII or send a special error code that the client can
resolve. Although I guess no one could fault us if "could not set language"
is reported not translated. ;-)
> I think that ultimately it's necessary to accept that there will be some
> window during connection startup where sending plain ASCII (English)
> messages is the best recourse.
Ultimately yes. But we currently handle the client encoding quite late in the
startup sequence so that many connection startup failure messages that are of
interest to normal users would likely be affected. So moving the client
encoding handling to the earliest possible phase would still be desirable.
