On Wed, 1 Sep 1999, Thomas Lockhart wrote:
> Date: Wed, 01 Sep 1999 02:55:48 +0000
> From: Thomas Lockhart <lockhart@alumni.caltech.edu>
> To: t-ishii@sra.co.jp
> Cc: Oleg Bartunov <oleg@sai.msu.su>, Oliver Elphick <olly@lfix.co.uk>,
> hackers@postgresql.org, 43702@bugs.debian.org
> Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
>
> > That shouldn't be too difficult, if we have an encoding infomation
> > with each text column or literal. Maybe now is the time to introuce
> > NCHAR?
Yes, postgres after 6.5 and especially recent win becomes very popular
and additional performance hit would be very in time. Does implementing
of NCHAR only could solve all problem with text, varchar etc ?
>
> I've been waiting for a go-ahead from folks who would use it. imho the
> way to do it is to use Postgres' type system to implement it, rather
> than, for example, encoding "type" information into each string. We
> can also define a "default encoding" for each database as a new column
> in pg_database...
go-ahead, Tom :-) I would use it.
>
> > BTW, it is interesting that people does not hesitate to enable
> > with-locale option even if they only use ASCII. I guess the
> > performance degration by enabling locale is not too small.
>
> Red Hat built their RPMs with locale enabled, and there is a
> significant performance hit. Implementing NCHAR would be a better
> solution, since the user can choose whether to use SQL_TEXT or the
> locale-specific character set at run time...
>
> - Thomas
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California
>
> ************
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83