| From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | "Tatsuo Ishii" <ishii(at)postgresql(dot)org> |
| Cc: | itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: default_text_search_config |
| Date: | 2007-10-05 11:30:13 |
| Message-ID: | 162867790710050430p2a9350bdpb451ae841e1e0c5b@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> 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.
> --
There is only one correct solution -> support of COLLATES. With
COLLATES you can choise locale per database, per table, per column,
per db operation. This is one point where PostgreSQL is late over
others.
Pavel Stehule
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-10-05 12:25:01 | Polymorphic arguments and composite types |
| Previous Message | Simon Riggs | 2007-10-05 10:58:42 | EXPLAIN doesnt show Datum sorts explicitly |