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@xxxxxxxxxxxxx>
To: "NTPT" <ntpt@xxxxxxxxxx>
Cc: <pgsql-general@xxxxxxxxxxxxxx>
Sent: Monday, January 29, 2007 12:33 AM
Subject: Re: [GENERAL] MULE_INTERNAL translation to win1250
"NTPT" <ntpt@xxxxxxxxxx> 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
