On Mon, Mar 28, 2016 at 5:57 PM, Stephen Frost <sfr...@snowman.net> wrote:
> Changed the thread name (we're no longer talking about release
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Oleg Bartunov <obartu...@gmail.com> writes:
> > > Should we start thinking about ICU ?
> > Isn't it still true that ICU fails to meet our minimum requirements?
> > That would include (a) working with the full Unicode character range
> > (not only UTF16) and (b) working with non-Unicode encodings. No doubt
> > we could deal with (b) by inserting a conversion, but that would take
> > a lot of shine off the performance numbers you mention.
> > I'm also not exactly convinced by your implicit assumption that ICU is
> > bug-free.
> We have a wiki page about ICU. I'm not sure that it's current, but if
> it isn't and people are interested then perhaps we should update it:
Good point, I forget about this page.
> If we're going to talk about minimum requirements, I'd like to argue
> that we require whatever system we're using to have versioning (which
> glibc currently lacks, as I understand it...) to avoid the risk that
> indexes will become corrupt when whatever we're using for collation
> changes. I'm pretty sure that's already bitten us on at least some
> RHEL6 -> RHEL7 migrations in some locales, even forgetting the issues
> with strcoll vs. strxfrm.
> Regarding key abbreviation and performance, if we are confident that
> strcoll and strxfrm are at least independently internally consistent
> then we could consider offering an option to choose between them.
> We'd need to identify what each index was built with to do so, however,
> as they would need to be rebuilt if the choice changes, at least
> until/unless they're made to reliably agree. Even using only one or the
> other doesn't address the versioning problem though, which is a problem
> for all currently released versions of PG and is just going to continue
> to be an issue.
Ideally, we should benchmarking all locales on all platforms for all kind
indexes. But that's big project.