> 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
