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

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 (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-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

pgsql-hackers by date

Next:From: Christof PetigDate: 1999-11-30 04:44:10
Subject: Re: [HACKERS] CORBA STATUS
Previous:From: Tom LaneDate: 1999-11-30 04:16:40
Subject: Re: [HACKERS] IN clause and INTERSECT not behaving as expected

pgsql-bugs by date

Next:From: MetalstormDate: 1999-12-01 02:39:56
Subject: Bug in CREATE SEQUENCE x MAXVAL x parsing?
Previous:From: Bruce MomjianDate: 1999-11-30 03:17:28
Subject: Re: [HACKERS] Problems in 6.5.3 with Multi-Byte encoding

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