Re: [PATCHES] Chinese GB18030 support is implemented!
От | Tatsuo Ishii |
---|---|
Тема | Re: [PATCHES] Chinese GB18030 support is implemented! |
Дата | |
Msg-id | 20020613.173619.104411214.t-ishii@sra.co.jp обсуждение исходный текст |
Список | pgsql-hackers |
[pgsql-announce removed and pgsql-hackers added] I have applied your patches with small corrections. Please grab the latest source and let me know if something is wrong. Thanks. -- Tatsuo Ishii > Hi Ishii-san, > > The patches are attached.Please apply it. > > Thanks, > Bill > > Tatsuo Ishii wrote: > > >>Hello, > >> > >>As postgresql is widely used in the world,many Chinese users are looking > >>forward to use such a high performanced database management > >>system.However since the Chinese new codepage standard GB18030 is not > >>completely supported,postgresql is limitted to be used in China. > >> > >>Now I have managed to implement the GB18030 support upon the latest > >>version,so the following functions are added after the patches are added. > >> > >>-Chinese GB18030 encoding is available on front-end side,while on > >>backend side,EUC_CN or MIC is used. > >>-Encoding convertion between MIC and GB18030 is implement. > >>-GB18030 locale support is available on front-end side. > >>-GB18030 locale test is added. > >> > >>Any help for testing with these patches and sugguestions for GB18030 > >>support are greatly appreciated. > >> > > > >We need to apply your pacthes to the current source tree(we are not > >allowed to add new feature stable source tree). Your pacthes for > >encnames.c pg_wchar.h and wchar.c are rejected due to the difference > >between 7.2 and current. > > > >Can you give me patches encnames.c pg_wchar.h and wchar.c against > >current? > > > >Unicode conversion map staffs ISO10646-GB18030.TXT utf8_to_gb18030.map > >UCS_to_GB18030.pl and gb18030_to_utf8.map are looks good for > >current. So I will apply them. > >-- > >Tatsuo Ishii > > > -- > /---------------------------/ > (Bill Huang) > E-mail:bill_huanghb@ybb.ne.jp > Cell phone:090-9979-4631 > /---------------------------/
В списке pgsql-hackers по дате отправления: