> 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.
SRA OSS, Inc. Japan
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2007-10-05 09:01:38|
|Subject: Release Notes Overview|
|Previous:||From: ITAGAKI Takahiro||Date: 2007-10-05 07:40:25|
|Subject: Re: default_text_search_config |