Re: [HACKERS] Re: [PATCHES] Postgres-6.3.2 locale patch (fwd)

From: Peter Mount <peter(at)taer(dot)maidstone(dot)gov(dot)uk>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: [PATCHES] Postgres-6.3.2 locale patch (fwd)
Date: 1998-06-04 08:58:12
Message-ID: Pine.LNX.3.95.980604094849.22664B-100000@taer.maidstone.gov.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 4 Jun 1998 t-ishii(at)sra(dot)co(dot)jp wrote:

> >In a same vein, for getting JDBC up to speed with this, we may need to
> >have a function on the backend that will handle the translation between
> >the encoding and Unicode. This would allow the JDBC driver to
> >automatically handle a new character set without having to write a class
> >for each package.
>
> I already have a patch to handle the translation on the backend
> between the encoding and SJIS (yet another encoding for Japanese).
> Translation for other encodings such as Big5(Chinese) and Unicode are
> in my plan.
>
> The biggest problem for Unicode is that the translation is not
> symmetrical. An encoding to Unicode is ok. However, Unicode to an
> encoding is like one-to-many. The reason for that is "Unification." A
> code point of Unicode might correspond to either Chinese, Japanese or
> Korean. To determine that, we need additional infomation what language
> we are using. Too bad. Any idea?

I'm not sure. I brought this up as it's something that I feel should be
done somewhere in the backend, rather than in the clients, and should be
thought about at this stage.

I was thinking on the lines of a function that handled the translation
between any two given encodings (ie it's told what the initial and final
encodings are), and returns the translated string (be it single or
multi-byte). It could then throw an error if the translation between the
two encodings is not possible, or (optionally) that part of the
translation would fail.

Also, having this in the backend would allow all the interfaces access to
international encodings without too much work. Adding a new encoding can
then be done just on the server (say by adding a module), without having
to recompile/link everything else.

--
Peter Mount, peter(at)maidstone(dot)gov(dot)uk
Postgres email to peter(at)taer(dot)maidstone(dot)gov(dot)uk & peter(at)retep(dot)org(dot)uk
Remember, this is my work email, so please CC my home address, as I may
not always have time to reply from work.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jose' Soares Da Silva 1998-06-04 10:13:31 Re: [PATCHES] Postgres-6.3.2 locale patch
Previous Message t-ishii 1998-06-04 08:16:13 Re: [HACKERS] Re: [PATCHES] Postgres-6.3.2 locale patch (fwd)