Search Postgresql Archives

Re: encoding of PostgreSQL messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux