From: | Hannu Krosing <hannu(at)trust(dot)ee> |
---|---|
To: | phd2(at)earthling(dot)net |
Cc: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, "'Oleg Bartunov'" <oleg(at)sai(dot)msu(dot)su>, "'hackers(at)postgresql(dot)org'" <hackers(at)postgreSQL(dot)org>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Subject: | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem |
Date: | 1999-06-12 18:16:53 |
Message-ID: | 3762A415.BC415D4C@trust.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Good | 1999-06-12 18:32:42 | Re: [HACKERS] "DML"...CREATE ACRONYM statement |
Previous Message | Tom Lane | 1999-06-12 16:42:32 | Re: [HACKERS] bug with aggregates |