Re: BUG #2685: Wrong charset of server messages on client
От | Sergiy Vyshnevetskiy |
---|---|
Тема | Re: BUG #2685: Wrong charset of server messages on client |
Дата | |
Msg-id | Pine.LNX.4.64.0610122141330.28687@uanet.vostok.net обсуждение исходный текст |
Ответ на | Re: BUG #2685: Wrong charset of server messages on client (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Tue, 10 Oct 2006, Tom Lane wrote: > Sergiy Vyshnevetskiy <serg@vostok.net> writes: >> Here is a new and improved patch, that closes security hole as well. > > We really can't consider a patch like this, because not only does it > ignore the problem of multiple spellings of encoding names, but it > actually breaks existing functionality on platforms with a variant > spelling of the name. I think a minimum requirement ought to be that > it work with any of the spellings recognized by initdb. Alright, that was too strict. But when server uses messages in LC_CTYPE encoding with data in database encoding and pushes this mix through database-to-client charset conversion - that's a bug. PostgreSQL bug. And "UTF-8 panic" is it's direct result. As a stop-gap I included a version of patch that breaks nothing. But it will fix the "wrong encoding" bug and "UTF-8 panic" only on those OS who recognize the supplied spelling. Linux and FreeBSD are among them. Cycling through possible spellings in SetDatabaseEncoding() is suboptimal. The time and place to do it is somewhere in the configure script. There we can fill pg_enc2localname_tbl with results of testing possible charset names. We can also just leave the patch as it is, because more and more OS learn more and more different charset name spellings every new version. Why waste too mush power chasing a horce that runs _to_you_? :)
В списке pgsql-bugs по дате отправления: