Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Postgres-6.3.2 locale patch

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: phd2(at)earthling(dot)net, Postgres Hackers List <hackers(at)postgresql(dot)org>, Jose Soares Da Silva <sferac(at)bo(dot)nettuno(dot)it>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Subject: Re: [PATCHES] Postgres-6.3.2 locale patch
Date: 1998-06-03 14:24:17
Message-ID: 35755C91.15D4BA9B@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi. I'm looking for non-English-using Postgres hackers to participate in
implementing NCHAR() and alternate character sets in Postgres. I think
I've worked out how to do the implementation (not the details, just a
strategy) so that multiple character sets will be allowed in a single
database, additional character sets can be loaded at run-time, and so
that everything will behave transparently.

I would propose to do this for v6.4 as user-defined packages (with
compile-time parser support) on top of the existing USE_LOCALE and MB
patches so that the existing compile-time options are not changed or
damaged.

So, the initial questions:

1) Is the NCHAR/NVARCHAR/CHARACTER SET syntax and usage acceptable for
non-English applications? Do other databases use this SQL92 convention,
or does it have difficulties?

2) Would anyone be interested in helping to define the character sets
and helping to test? I don't know the correct collation sequences and
don't think they would display properly on my screen...

3) I'd like to implement the existing Cyrillic and EUC-jp character
sets, and also some European languages (French and ??) which use the
Latin-1 alphabet but might have different collation sequences. Any
suggestions for candidates??

                       - Tom

Responses

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-06-03 14:46:49
Subject: Re: [HACKERS] keeping track of connections
Previous:From: Hal SnyderDate: 1998-06-03 14:20:30
Subject: Re: [HACKERS] keeping track of connections

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group