Re: [bug fix] multibyte messages are displayed incorrectly on the client
От | MauMau |
---|---|
Тема | Re: [bug fix] multibyte messages are displayed incorrectly on the client |
Дата | |
Msg-id | 2C7051B8F82C4461A1AB02FE9A2E8CF1@maumau обсуждение исходный текст |
Ответ на | Re: [bug fix] multibyte messages are displayed incorrectly on the client (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: [bug fix] multibyte messages are displayed incorrectly on the
client
|
Список | pgsql-hackers |
From: "Noah Misch" <noah@leadboat.com> > Better to attack that directly. Arrange to apply any client_encoding > named in > the startup packet earlier, before authentication. This relates to the > TODO > item "Let the client indicate character encoding of database names, user > names, and passwords". (I expect such an endeavor to be tricky.) Unfortunately, character set conversion is not possible until the database session is established, since it requires system catalog access. Please the comment in src/backend/utils/mb/mbutils.c: * During backend startup we can't set client encoding because we (a)* can't look up the conversion functions, and (b) maynot know the database* encoding yet either. So SetClientEncoding() just accepts anything and* remembers it for InitializeClientEncoding()to apply later. I guess that's why Tom-san suggested the same solution as my patch (as a compromise) in the below thread, which is also a TODO item: Re: encoding of PostgreSQL messages http://www.postgresql.org/message-id/19896.1234107496@sss.pgh.pa.us From: "Alvaro Herrera" <alvherre@2ndquadrant.com> > The problem is that if there's an encoding mismatch, the message might > be impossible to figure out. If the message is in english, at least it > can be searched for in the web, or something -- the user might even find > a page in which the english error string appears, with a native language > explanation. I feel like this, too. Being readable in English is better than being unrecognizable. Regards MauMau
В списке pgsql-hackers по дате отправления: