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

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 (view raw or flat)
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

pgsql-hackers by date

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

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