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
