Received: from kodu.home.ee (isdn-54.uninet.ee [194.204.0.118]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA30500 for ; Sat, 12 Jun 1999 14:10:14 -0400 (EDT) (envelope-from hannu@trust.ee) Received: from trust.ee (hannu@localhost [127.0.0.1]) by kodu.home.ee (8.8.7/8.8.7) with ESMTP id VAA00528; Sat, 12 Jun 1999 21:16:53 +0300 Sender: hannu@kodu.home.ee Message-ID: <3762A415.BC415D4C@trust.ee> Date: Sat, 12 Jun 1999 21:16:53 +0300 From: Hannu Krosing Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?= X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.6 i686) X-Accept-Language: en MIME-Version: 1.0 To: phd2@earthling.net CC: Thomas Lockhart , "'Oleg Bartunov'" , "'hackers@postgresql.org'" , Tatsuo Ishii Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oleg Broytmann wrote: > > Hi! > > On Fri, 11 Jun 1999, Thomas Lockhart wrote: > > > And what a pros and cons for NCHAR? > > I was hoping you would tell me! :) > > I can see only one advantage for NCHAR - those fields that aren't NCHAR > will not use strcoll() for comparison. > But I cannot remember one filed in my database that does not contain > russian characters. Even my WWW logs contain them. what about the tables beginning with pg_ ? Are the system tables currently affected by --enable-locale ? > So in any case I am forced to make all my fields NCHAR, and this is > exactly what we have now - postgres compiled with --enable-locale makes all > char NCHAR. Well, the problem is that while I do occasionally need cyrillic chars, I also need English, Estonian, Finnish/Swedish, Latvian and Lithuanian. The only two of them that don't have overlapping character codes are Russian (all chars >127) and English (all < 128) My current solution is to run without --enable-locale and do all the sorting in the client. But it would be often useful to have language specific columns. -------------------- Hannu