Re: [HACKERS] Implications of multi-byte support in a distribution

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, hackers(at)postgresql(dot)org, 43702(at)bugs(dot)debian(dot)org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
Date: 1999-09-01 02:55:48
Message-ID: 37CC95B4.4501F393@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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?

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...

> 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 1999-09-01 05:48:59 Re: [HACKERS] Implications of multi-byte support in a distribution
Previous Message Tatsuo Ishii 1999-09-01 02:30:44 Re: [HACKERS] Implications of multi-byte support in a distribution