Bruce, et al,
given the thread partially quoted below would this warrant a
TODO item "improve communication of encoding between client
and server regarding early startup messages" ?
A very usable band-aid for 8.4 - short of a proper fix -
would be the minimal-invasive sending of messages in 7-bit
English until server_encoding can be retrieved by the client
by current means.
Thanks,
Karsten
On Thu, Jan 01, 2009 at 08:33:56PM +0200, Peter Eisentraut wrote:
> Subject: Re: [GENERAL] encoding of PostgreSQL messages
> User-Agent: KMail/1.9.9
>
> 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.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346