On Tue, Jun 28, 2016 at 3:50 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Uhmm. Until now I saw all this ICU thing as having fringe benefit on
> strange platforms only, but it is seeming more and more like we need to
> take it seriously. I'm not prepared to spend effort on it myself,
> though.
Let me put it this way: If we lived in a world where
internationalization was a new idea, and someone proposed collation
support that relied on the OS today, the patch would be rejected in
about 2 minutes. The author would be pointed in the direction of
"Notes to Operator Class Implementors" within the nbtree README.
There are numerous user-visible benefits to ICU support, too, like:
* Case-insensitive collations become possible (with work in other
areas). No more contrib/citext hack. This is something that we seem to
want to work towards.
* Abbreviated keys in indexes with collated text becomes possible.
(Already mentioned that abbreviated keys for collated text + sorting
are effectively reintroduced.)
* More useful collations available for certain languages, such as
Japanese. Apparently, the JIS X 4061 algorithm produces results that
Japanese people find more useful, but glibc doesn't support it, and
never will.
* We might be able to document WAL compatibility usefully, now. The
documentation never gets around to explaining what two instances are
compatible for the purposes of physical replication. I can't think of
any other factor that prevents us from locking that down.
* Upgrade major OS versions without difficulty.
* User-defined collations, where you can mix and match certain facets
of how text is sorted as you please. Basically, ICU offers rich
functionality that we can bubble up to our users without too much
effort, as other database systems have.
--
Peter Geoghegan