On Fri, Nov 28, 2014 at 8:43 AM, Peter Eisentraut <pete...@gmx.net> wrote: > At the moment, this is probably just an experiment that shows where > refactoring and better abstractions might be suitable if we want to > support multiple locale libraries. If we want to pursue ICU, I think > this could be a useful third option.
FWIW, I think that the richer API that ICU provides for string transformations could be handy in optimizing sorting using abbreviated keys. For example, ICU will happily only produce parts of sort keys (the equivalent of strxfrm() blobs) if that is all that is required [1]. I think that ICU also allows clients to parse individual primary weights in a principled way (primary weights tend to be isomorphic to the Unicode code points in the original string). I think that this will enable order-preserving compression of the type anticipated by the Unicode collation algorithm [2]. That could be useful for certain languages, like Russian, where the primary weight level usually contains multi-byte code points with glibc's strxfrm() (this is generally not true of languages that use the Latin alphabet, or of East Asian languages). Note that there is already naturally a form of what you might call compression with strxfrm() [3]. This is very useful for abbreviated keys. [1] http://userguide.icu-project.org/collation/architecture [2] http://www.unicode.org/reports/tr10/#Run-length_Compression [3] http://www.postgresql.org/message-id/cam3swztywe5j69tapvzf2cm7mhskke3uhhnk9gluqckkwqo...@mail.gmail.com -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
