Re: Multi-byte character bug

> > There's no character code in EUC_TW (CNS 11643-1992)
> > corresponding to Big5 0xc05c. That's why PostgreSQL complains.
>
>
> But I've created another db using MULE_INTERNAL encoding, the same error
> reported, why ?

Since Big5 representation of MULE_INTERNAL is actually "leading
character"+EUC_TW. i.e.

> Why don't Postgres directly support BIG5 in server side

It's because of pury technical reason. Handling those encodings
containing bytes < 0x80 in second (or third) byte of a word confuses
our SQL parser. I think it's not impossible for the parser to handle
Big5, but if we make such a change, the parser would not be able to
other encodings. If you have a good idea to overcome these problems,
we are wellcome.

> as BIG5 is the
> main encoding using for Traditional Chinese communities, i.e. HK &
> Taiwan ? As EUC_TW do not have complete correspondings char in BIG5,
> this will seriously prevent the Traditional Chinese communities for
> using Postgresql !

Just a curious. Why do people living in those area prefer Big5 over
EUC_TW? I thought EUC_TW (or CNS 11643-1992) was defined by the
goverment in Taiwan. Is there any technical superiority in Big5?
Or maybe "don't know why but just many peole use Big5":-)
--
Tatsuo Ishii