From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: default_text_search_config |
Date: | 2007-10-05 08:21:03 |
Message-ID: | 20071005.172103.66728907.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-10-05 09:01:38 | Release Notes Overview |
Previous Message | ITAGAKI Takahiro | 2007-10-05 07:40:25 | Re: default_text_search_config |