Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem

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

In response to

Responses

Browse pgsql-hackers by date

  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