Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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.
This sounds like you want to completely reimplement all of the locale handling
provided by the OS? That seems like a dead-end approach to me. There's no way
your handling will ever be as complete or as well optimized as some OS's.
Better to find ways to use the OS gettext and locale handling on platforms
that provide good interfaces. On platforms that don't provide good interfaces
either don't support the features or use some third party library to provide
a good implementation.
The only thing you really need in the database is a second parameter on all
the collation functions like strxfrm(col,locale) etc. Then functional indexes
take care of almost everything.
The only advantage to adding locales per-column and/or per-index is the
notational simplicity. Queries could do simple standard expressions and not
have to worry about calling strxfrm or other locale-specific functions all the
time. I'm not sure it's worth the complexity of having to deal with
"WHERE x>y" where x and y are in different locales though.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
