From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: phd2@earthling.net, "'Oleg Bartunov'" <oleg@sai.msu.su>
Cc: 'hackers@postgresql.org' <hackers@postgreSQL.org>
Cc: Tatsuo Ishii <t-ishii@sra.co.jp>
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
Date: Fri, 11 Jun 1999 09:54:08 +0900
Message-ID: <199906110054.JAA01357@ext16.sra.co.jp> (raw)
In-Reply-To: <375FD663.4645D0A@alumni.caltech.edu>
> istm that the Russian and Japanese contingents could represent the
> needs of multibyte and locale concerns very well. So, we should ask
> ourselves some questions to see if we can make *progress* in evolving
> our text handling, rather than just staying the same forever.
>
> SQL92 suggests some specific text handling features to help with
> non-ascii applications. "national character" is, afaik, the feature
> which would hold an installation-wide local text type. "collations"
> would allow other text types in the same installation, but SQL92 is a
> bit fuzzier about how to make them work.
>
> Would these mechanisms work for people? Or are they so fundamentally
> flawed or non-standard (it is from a standard, but I'm not sure who
> implements it)?
In my opinion, introducing NCHAR is useful at least for single byte
codes. Although I'm not familiar with single byte languages, I see
strong demands for NCHAR through recent discussions.
I don't mean it's useless for multibyte, however. As far as I know
locales for multibyte provided by any OS are totally broken especially
in COLLATE(I seriously doubt existing locale framework work for
multibyte). It would be nice to have our own locale data for COLLATE
somewhere in our system like some commercial dbms do, or even better
user defined collations allowed (this is already in the standard).
I have a feeling that I'm going to implement CREATE CHARSET through
slightly modifying the multibyte support code that currently only
allows predefined charset. That will be the first step toward CREATE
COLLATE, NCHAR etc....
---
Tatsuo Ishii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: t-ishii@sra.co.jp, lockhart@alumni.caltech.edu, oleg@sai.msu.su, hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
In-Reply-To: <199906110054.JAA01357@ext16.sra.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox