> The correct solution is probably we will have multiple locales in
> single database cluster. We should set the locale after deciding
> the encoding nowm, but I think the current implementation is wrong
> because locale depends on encoding, but the opposite is not true.
> (locale = 'language_country.*encoding*')
>
> If you will go to the multiple text-search support, we'd better to
> get done the locale issue first. It might affect your new parser.
I'm not sure the locale per database solution is a silver bullet.
With this, still we cannot solve the issue, for example, a LATIN1
encoded text includes several languages at a time, thus it needs
multiple locales. Or we cannot have multiple different language
columns, tables at a time because it requires multiple locales. Same
thing can be said to Unicode too. After all it seems a half baked
solution to me.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
