Re: [HACKERS] Implications of multi-byte support in a distribution - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: [HACKERS] Implications of multi-byte support in a distribution
Date
Msg-id 37CC95B4.4501F393@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] Implications of multi-byte support in a distribution  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: [HACKERS] Implications of multi-byte support in a distribution  (Oleg Bartunov <oleg@sai.msu.su>)
List 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@alumni.caltech.edu
South Pasadena, California


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
Next
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution