Re: Dynamic collation support - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Dynamic collation support
Date
Msg-id CAHyXU0yrD01pXU_-b_ZxsKaVHzwD5ybqpOz786RfszcC7t1vYA@mail.gmail.com
Whole thread Raw
In response to Re: Dynamic collation support  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Building 9.4 rpm for Red Hat 5
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: plpython3 package absent in 9.5 repository