Received: from ext16.sra.co.jp (IDENT:root@ykh28DS27.kng.mesh.ad.jp [133.205.214.27]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA50191 for ; Thu, 10 Jun 1999 21:04:18 -0400 (EDT) (envelope-from t-ishii@ext16.sra.co.jp) Received: from ext16.sra.co.jp (t-ishii@localhost [127.0.0.1]) by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id JAA01357; Fri, 11 Jun 1999 09:54:08 +0900 Message-Id: <199906110054.JAA01357@ext16.sra.co.jp> To: Thomas Lockhart cc: phd2@earthling.net, "'Oleg Bartunov'" , "'hackers@postgresql.org'" , Tatsuo Ishii Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem From: Tatsuo Ishii Reply-To: t-ishii@sra.co.jp In-reply-to: Your message of Thu, 10 Jun 1999 15:14:43 GMT. <375FD663.4645D0A@alumni.caltech.edu> Date: Fri, 11 Jun 1999 09:54:08 +0900 Sender: t-ishii@ext16.sra.co.jp > 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