From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | pgman(at)candle(dot)pha(dot)pa(dot)us |
Cc: | olly(at)lfix(dot)co(dot)uk, pgsql-bugs(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org, 50388(at)bugs(dot)debian(dot)org |
Subject: | Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding |
Date: | 1999-11-30 04:43:27 |
Message-ID: | 19991130134327B.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
> Anyone want to comment on this? BIG5 anyone?
>
> > With PostgreSQL compiled with support for locales and multi-byte encoding:
> >
> > initdb -e BIG5
> >
> > [start postmaster]
> > psql template1
> > \dS causes a segmentation fault in the backend
The answer is:
You should not do initdb with BIG5, instead you could do:
initdb -e EUC_TW
BIG5 and EUC_TW are both for traditional Chinese, only EUC_TW can be
used for the proffered encoding for the backend, however. In the
setting above, you could use EUC_TW for the frontend side and BIG5 as
well. To use BIG5 in the fronend, you set the environment variable
PGCLIENTENCODING to "BIG5" if you use psql or applications those are
using libpq. In this case, an automatic code conversion between BIG5
and EUC_TW will be performed in the backend.
I'll add the code to prevent BIG5 for initdb -e in the next release.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Metalstorm | 1999-12-01 02:39:56 | Bug in CREATE SEQUENCE x MAXVAL x parsing? |
Previous Message | Bruce Momjian | 1999-11-30 03:17:28 | Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding |
From | Date | Subject | |
---|---|---|---|
Next Message | Christof Petig | 1999-11-30 04:44:10 | Re: [HACKERS] CORBA STATUS |
Previous Message | Tom Lane | 1999-11-30 04:16:40 | Re: [HACKERS] IN clause and INTERSECT not behaving as expected |