Skip site navigation (1) Skip section navigation (2)

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-10 15:57:35
Message-ID: Pine.LNX.4.64.0610101840210.25775@uanet.vostok.net (view raw or flat)
Thread:
Lists: pgsql-bugs
On Tue, 10 Oct 2006, Tom Lane wrote:

> "Sergiy Vyshnevetskiy" <serg(at)vostok(dot)net> writes:
>> Convert server messages to database charset.
>
> This has been discussed before:
> http://archives.postgresql.org/pgsql-patches/2005-08/msg00245.php
>
> The magic pg_enc2iananame_tbl[] you reference in your patch does not exist,
> and if it did exist it wouldn't work on all platforms, since encoding
> names aren't sufficiently well standardized :-(

It's not magic, it's from ICU patch. Want me to send you a copy? :)

>> This, however, uncovers another bug: PostgreSQL dumps the messages into
>> stderr/syslog as-is, without converting database data from database charset
>> to charset from LC_MESSAGES.
>
> I'm quite unconvinced that that's a bug.  If we tried to do a conversion
> here, it would be trivial to set up denials of service for logging ---
> just include a character in a comment in your SQL command that cannot be
> converted to the LC_MESSAGES character set.

They have to be printed as escape sequences. I think that dumping raw 
string data in log without converting them to printable form can be used 
to mess up log viewer at least. (At most this can be a security breach.)

Having row multibyte characters mixed with characters in LC_CTYPE in the 
log makes it less useful. Syslog would mangle them further to a complete 
unrecognition.

In response to

Responses

pgsql-bugs by date

Next:From: Sergiy VyshnevetskiyDate: 2006-10-10 16:11:03
Subject: Re: BUG #2685: Wrong charset of server messages on client
Previous:From: Tom LaneDate: 2006-10-10 15:50:36
Subject: Re: BUG #2684: Memory leak in libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group