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_? :)