> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq