I made a some future investigation. I find and identified an exact line in
databse. Exact column that cause a problem, I am able to select column into
testtable while in "testtable" it retain its bad behavior. fortunally,
this row does not contain vital
data so I can drop it rather without a bigger problem, but I would like to
know why....
I am able to identify a single character that cause a problem in real data
and in "testtable" too. (rather character combination using substring
function - it seems that in certain point it take two characters as single
16bit one ) but I am not able to reproduce this behavior on fresh table
using "insert" and "select" statements. Please give me a some tip where to
search and what else informations to provide.
thank you.
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "NTPT" <ntpt@centrum.cz>
Cc: <pgsql-general@postgresql.org>
Sent: Monday, January 29, 2007 12:33 AM
Subject: Re: [GENERAL] MULE_INTERNAL translation to win1250
> "NTPT" <ntpt@centrum.cz> writes:
>> Without "set client_encoding to win1250" query works. I am curious why
>> there
>> is a MULE_INTERNAL mentioned even when \l+ say that corresponding
>> database
>> is created with (and even all the cluster) LATIN2 encoding.
>
> The conversions between LATIN2 and WIN1250 go by way of MULE_INTERNAL to
> reduce duplication of code. It shouldn't make any difference to the end
> result though. Are you sure that the characters you're using are
> supposed to have representations in both character sets?
>
>> 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.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.410 / Virus Database: 268.17.12/654 - Release Date: 27.1.2007
>
>