Re: Dynamic collation support
От | Pavel Stehule |
---|---|
Тема | Re: Dynamic collation support |
Дата | |
Msg-id | CAFj8pRD=fLX5BfWu488WpTx84nMdwjuP_yM9aHaPvWV-Cjg_8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Dynamic collation support (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Dynamic collation support
|
Список | pgsql-general |
2016-01-19 20:04 GMT+01:00 Merlin Moncure <mmoncure@gmail.com>:
On Tue, Jan 19, 2016 at 11:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Tue, Jan 19, 2016 at 9:15 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>> Different collates requires different plans - so using dynamic SQL is much
>>> more correct.
>>> It is same like using variables as columns or tablenames.
>
>> Right -- I get it, and I understand the planner issues. But the
>> amount of revision that goes into a database that internationalizes
>> can be pretty large. To do it right, any static sql that involves
>> string ordering can't be used. pl/sql also can't be used. ISTM this
>> is impolite to certain coding styles.
>
> Well, it's the way the SQL committee specified collations to work, so
> we're pretty much stuck with that syntax.
I understand. It's water under the bridge if a strxfrm() wrapper
could deliver the goods here. Changing:
ORDER BY foo
to
ORDER BY strxfrm(foo, _CollationLocale)
this mechanism was used more time in Czech multilanguage applications
Orafce.nlssort use it.
https://github.com/orafce/orafce/blob/master/others.c
https://github.com/orafce/orafce/blob/master/others.c
Regards
Pavel
is a nice escape route where _CollationLocale gets suddenly brought on
to the table. It's going to be awfully slow, but in many cases that's
acceptable. At least I think so -- I have to play with it.
merlin
В списке pgsql-general по дате отправления: