>I think I saw from the list of developers that you wrote a lot of the
>multiu-byte code. Is that correct? If so my grateful thanks.
Yes, I'm responsible for the code multi-byte.
>Are there any limitations or gotchas about using unicode everywhere?
>
>Specifically
>
>1. Column length. Is this measured in unicode characters or do I need to
>increase the length of Varchars? ie is a varchar(10) certain to hold 10
>unicode characters?
When you define varchar(n), n should be counted in bytes, not
characters.
We assume Unicode is input as UTF-8 encoding. In UTF-8, 10 ASCII chars
take 10 bytes. So varchar(10) will hold 10 Unicode chars if they are
all ASCII. However, if you use ISO8859 chars they will take 2 bytes
for each letter. If you use KANJI, 3 bytes for each letter. You could
use octet_length() to measure the size of a Unicode string in bytes.
>2. Indexing. What sort order will I get from an index or an order by for
>unicode characters.
It will sorted in the order of Unicode code point.
>Can this be customised.
Currently no.
>Generally I try to do any
>really important sorting in Java where I can use the correct sort order
>for the locale.
>3. Upper/lowercase. I have been using separate columns for uppercase
>versions of names etc again so that the case changes can be done by the
>client which will know the correct rules for the locale where the data
>is entered. What do upper/lower case functions in Postgresql do with
>unicode?
I think it will related to locale. I'm not sure but I've heard about
Unicode locale. If it really exists, you could do:
configure --with-mb=UNICODE --with-locale
so that upper/lower works for Unicode.
>4. Are there any limitations on what I use to write triggers? Can all
>the different ways work reliably with unicode?
I'm not sure but it should work with triggers.
--
Tatsuo Ishii