On Sun, Jan 28, 2007 at 06:33:16PM -0500, Tom Lane wrote: > "NTPT" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
