Re: Internationalization

Tom Lane wrote:

> Dennis Gearon <gearond(at)fireserve(dot)net> writes:
>
>>Is there anyway for a single statement to access more than one database?
>>Could a query, regexes, etc be facing indexes in different
>>encodings/sorting collations if different databases in a cluster had
>>different encodings/collations?
>
>
> The indexes on the shared system tables (eg, pg_database) are the only
> issue here. One possible solution is to require that no locale-aware
> datatypes ever be used in these indexes. I think right now this is true
> because "name" doesn't use locale-aware sorting; but we'd have to be
> careful not to break the restriction in future.
>
> regards, tom lane
>
Tom what about table names? Isn't it part of the SQL spec to be able to set table names to other langauges other than English?

----------------------

I've researched most of the databases out there that will tell you anything about how they have internationlized them. By a vast majority, I have found them using UTF16 for ALL internals, in memory or CPU. This does double most non oriental langauge application's memory image. But, memory is cheap, and the desktop/Intel server market is just about to go to 64 bit and use much more memory.

Based on my research, all characters for most human langauges are able to be displayed in one - 2 byte, 16 bit char via UTF16. I am going to do some more research on that.

PROBABLY, most of them use UTF16 on the disk as well. Since most slow processes are IO bound, using an 8bit text datatype, WHEN possible, and converting on the fly might be a good way to keep some speed while truly making an ANSI spec, international database. I'm probably all wet though.