Re: Dynamic collation support
От | Merlin Moncure |
---|---|
Тема | Re: Dynamic collation support |
Дата | |
Msg-id | CAHyXU0yrD01pXU_-b_ZxsKaVHzwD5ybqpOz786RfszcC7t1vYA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Dynamic collation support (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-general |
On Tue, Jan 19, 2016 at 1:15 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > 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 wow! that's perfect! -- thanks. merlin
В списке pgsql-general по дате отправления: