Sender: lockhart@trends.net
Message-ID: <3763D40D.72D0972F@alumni.caltech.edu>
Date: Sun, 13 Jun 1999 15:53:49 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
MIME-Version: 1.0
To: Hannu Krosing <hannu@trust.ee>
CC: phd2@earthling.net, "'Oleg Bartunov'" <oleg@sai.msu.su>,
	"'hackers@postgresql.org'" <hackers@postgreSQL.org>,
	Tatsuo Ishii <t-ishii@sra.co.jp>
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
References: <Pine.LNX.4.04.9906121825030.28833-100000@emerald.netskate.ru>
	<3762A415.BC415D4C@trust.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Well, the problem is that while I do occasionally need cyrillic chars,
> I also need English, Estonian, Finnish/Swedish, Latvian and Lithuanian.
> The only two of them that don't have overlapping character codes are
> Russian (all chars >127) and English (all < 128)
> My current solution is to run without --enable-locale and do all the
> sorting
> in the client. But it would be often useful to have language specific
> columns.

Great! You're our representative for multi-charset usage :)

Perhaps you can think about and comment on the SQL92 features which
support this, and whether that kind of capability would suit your
needs. Of course, we would need to start getting specific about how to
map those generic features into a Postgres implementation...

btw, istm that we could make things somewhat backward compatible by
allowing the backend to be built with CHAR and NCHAR always mapped to
NCHAR.

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California