| From: | Michael Fuhr <mike(at)fuhr(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | NTPT <ntpt(at)centrum(dot)cz>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: MULE_INTERNAL translation to win1250 |
| Date: | 2007-01-29 02:27:12 |
| Message-ID: | 20070129022712.GA72978@winnie.fuhr.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sun, Jan 28, 2007 at 06:33:16PM -0500, Tom Lane wrote:
> "NTPT" <ntpt(at)centrum(dot)cz> writes:
> > May be a bug in charset translation routines of postgres ?
>
> If you think that, you need to provide us with the exact codes that are
> being mistranslated and what you think they should translate to.
I wonder if the OP is doing something like this:
test=> SELECT getdatabaseencoding();
getdatabaseencoding
---------------------
LATIN2
(1 row)
test=> SHOW client_encoding;
client_encoding
-----------------
win1250
(1 row)
test=> CREATE TABLE test (t text);
CREATE TABLE
test=> INSERT INTO test VALUES (E'\202\232'); -- \202=0x82, \232=0x9a
INSERT 0 1
test=> SELECT * FROM test;
ERROR: character 0x829a of encoding "MULE_INTERNAL" has no equivalent in "WIN1250"
The intent might be that E'\202\232' is a string in the client's
encoding, where it would represent the same characters as Unicode
<U+201A SINGLE LOW-9 QUOTATION MARK, U+0161 LATIN SMALL LETTER S
WITH CARON> (I'm using Unicode as the pivot for convenience). But
the backend is handling the string in the database's encoding, where
it represents <U+0082,U+009A>, which are control characters that
don't have mappings in win1250; hence the conversion error when the
client tries to read the data.
Just a guess.
--
Michael Fuhr
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Paul Lambert | 2007-01-29 02:50:35 | Load balancing across disks |
| Previous Message | Pierre Thibaudeau | 2007-01-29 02:26:59 | Re: tsearch2, locale, UTF-8 and Windows |