From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | pgman(at)candle(dot)pha(dot)pa(dot)us |
Cc: | girgen(at)pingpong(dot)net, john(at)geeknet(dot)com(dot)au, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch for collation using ICU |
Date: | 2005-05-08 00:08:39 |
Message-ID: | 20050508.090839.85414799.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Palle Girgensohn wrote:
> >
> > --On l?rdag, maj 07, 2005 23.15.29 +1000 John Hansen <john(at)geeknet(dot)com(dot)au>
> > wrote:
> >
> > > Btw, I had been planning to propose replacing every single one of the
> > > built in charset conversion functions with calls to ICU (thus making pg
> > > _depend_ on ICU), as this would seem like a cleaner solution than for us
> > > to maintain our own conversion tables.
I don't buy it. If current conversion tables does the right thing, why
we need to replace. Or if conversion tables are not correct, why don't
you fix it? I think the rule of character conversion will not change
frequently, especially for LATIN languages. Thus maintaining cost is
not too high.
--
Tatsuo Ishii
> > > ICU also has a fair few conversions that we do not have at present.
>
> That is a much larger issue, similar to our shipping our own timezone
> database. What does it buy us?
>
> o Do we ship it in our tarball?
> o Is the license compatible?
> o Does it remove utils/mb conversions?
> o Does it allow us to index LIKE (next high char)?
> o Does it allow us to support multiple encodings in
> a single database easier?
> o performance?
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2005-05-08 00:08:45 | Re: Patch for collation using ICU |
Previous Message | Josh Berkus | 2005-05-07 23:44:56 | Fix PID file location? |