Re: BUG #2685: Wrong charset of server messages on client

From: Sergiy Vyshnevetskiy <serg(at)vostok(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2685: Wrong charset of server messages on client
Date: 2006-10-12 19:50:27
Message-ID: Pine.LNX.4.64.0610122141330.28687@uanet.vostok.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, 10 Oct 2006, Tom Lane wrote:

> Sergiy Vyshnevetskiy <serg(at)vostok(dot)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_? :)

Attachment Content-Type Size
enc.diff text/plain 2.3 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Sergiy Vyshnevetskiy 2006-10-13 08:50:39 BUG #2692: psql sends natively-localized strings to database without setting client_encoding first
Previous Message Ille vieljans 2006-10-12 19:08:43 BUG #2691: Server did not start. Error: Could not create log file.