Re: MULE_INTERNAL translation to win1250 - Mailing list pgsql-general

From NTPT
Subject Re: MULE_INTERNAL translation to win1250
Date
Msg-id 008b01c74352$66da4bb0$62d2c3d5@wbp1
Whole thread Raw
In response to MULE_INTERNAL translation to win1250  ("NTPT" <ntpt@centrum.cz>)
List pgsql-general
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
>
>


pgsql-general by date:

Previous
From: Douglas McNaught
Date:
Subject: Re: Load balancing across disks
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Load balancing across disks