Skip site navigation (1) Skip section navigation (2)

Re: oh, i don't know did it is a bug or not.

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: terry(at)aitc(dot)com(dot)tw
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: oh, i don't know did it is a bug or not.
Date: 2002-04-16 01:08:46
Message-ID: 20020416100846Y.t-ishii@sra.co.jp (view raw or flat)
Thread:
Lists: pgsql-bugs
> the problem is
> my postgresql compile with enable multi bytes = unicode and my default
> language is BIG5 encoding, in previous version of postgresql 7.1 
> i can use unicode encoding to do my back-end encoding and client
> encoding set to BIG5, with this setting i can insert a chinese word code
> (0xf9d6) in to db (ps: it is not standard of BIG5, it is MS950), another
> word (0xea4d) work.
> but now
> in 7.2 when i insert that word into db, i got a "local_to_utf: could not convert (0xf9d6) BIG5 to UTF-8. Ignored"
> it seems very bad for me.
> but i have try another back-end encoding, the mule_internal and client
> big5 is work with that word.
> i remember that word is ok for oracle 8i with unicode encoding. 
> so that is a standard of unicode,why in 7.2 is fail?

Hard to belive. Neither 7.1 and 7.2 has a mapping from 0xf9d6(BIG5) to
0xea4d(UTF-8). Take a look at
src/backend/utils/mb/Unicode/big5_to_utf8.map.

BTW, if you really want to the conversion between 0xf9d6 and 0xea4d,
you could add it to big5_to_utf8.map and utf8_to_big5.map.
Hope this helps,
--
Tatsuo Ishii


In response to

pgsql-bugs by date

Next:From: Thomas LockhartDate: 2002-04-16 02:33:05
Subject: Re: Bug #633: CASE statement evaluation does not short-circut
Previous:From: Bruce MomjianDate: 2002-04-16 00:54:26
Subject: Re: 7.2 crash...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group