From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: A rough roadmap for internationalization fixes |
Date: | 2003-11-25 15:53:42 |
Message-ID: | 27798.1069775622@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Actually, what will more likely happen is that we'll define a collation as
> a collection of one or more support functions, the equivalents of
> strxfrm() and possibly a few more. Then it will be up to those functions
> to define the collation order. The server will provide utility functions
> that will facilitate implementing a collation order that follows the
> Unicode collation algorithm, but you could just as well implement one
> using memcmp() or whatever you like.
That sounds like a good plan to me. Personally I'd want a
memcmp()-based collation implementation available, so that people who
don't care about sorting anything beyond 7-bit ASCII don't need to pay
a lot of overhead.
We have seen over and over that strcoll() is depressingly slow in some
locales (at least on some platforms). Do you have any feeling for the
real-world performance of the Unicode algorithm?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-25 15:56:00 | Re: A rough roadmap for internationalization fixes |
Previous Message | Brian Hirt | 2003-11-25 15:36:20 | patch for pg_autovacuum |