Search Postgresql Archives

Re: Dynamic collation support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2016-01-19 20:04 GMT+01:00 Merlin Moncure <mmoncure@xxxxxxxxx>:
On Tue, Jan 19, 2016 at 11:11 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
> Merlin Moncure <mmoncure@xxxxxxxxx> writes:
>> On Tue, Jan 19, 2016 at 9:15 AM, Pavel Stehule <pavel.stehule@xxxxxxxxx> 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

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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux