Re: A rough roadmap for internationalization fixes - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: A rough roadmap for internationalization fixes
Date
Msg-id 20031125.182128.52163031.t-ishii@sra.co.jp
Whole thread Raw
In response to A rough roadmap for internationalization fixes  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: A rough roadmap for internationalization fixes  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
> OK, I've been spreading rumours about fixing the internationalization
> problems, so let me make it a bit more clear.  Here are the problems that
> need to be fixed:
> 
> - Only one locale per process possible.
> 
> - Only one gettext-language per process possible.
> 
> - lc_collate and lc_ctype need to be held fixed in the entire cluster.
> 
> - Gettext relies on iconv character set conversion, which relies on
>   lc_ctype, which leads to a complete screw-up in the server because of
>   the previous item.
> 
> - Locale fixed per cluster, but encoding fixed per database, unware
>   of each other, don't get along.
> 
> - No support for upper/lower with multibyte encoding.
> 
> - Implementation of Unicode horribly incomplete.
> 
> These are all dependent on each other and sort of flow into each other.
> 
> Here is a proposed ordering of steps toward improving the situation:
> 
> 1. Take out the character set conversion routines from the backend and
> make them a library of their own.  This could possibly be modelled after
> iconv, but not necessarily.  Or we might conclude that we can just use
> iconv in the first place.

How do you handle user-defined conversions?

> 2. Reimplement gettext to use 1. and allow switching of language and
> encoding at run-time.
> 
> 3. Implement Unicode collation algorithm and character classification
> routines that are aware of 1.  Use that in place of system locale
> routines.

I don't see a relationship between Unicode and the one you are going
to replace the system locale routines. If you are going to the
direction for an "Unicode central" implementation, I will object.

> 4. Allow choice of locale per database.  (This should be fairly easy after
> 3.)
> 
> 5. Allow choice of locale per column and implement collation coercion
> according to SQL standard.
> 
> This could easily take a long time, but I feel that even if we have to
> stop after 2., 3., or 4. at feature freeze, we'd be a lot farther.
> 
> Comments?  Anything else that needs fixing?
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Build farm
Next
From: Dennis Bjorklund
Date:
Subject: Re: A rough roadmap for internationalization fixes