Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding

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

In response to

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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