| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ICU integration |
| Date: | 2017-02-09 18:01:06 |
| Message-ID: | CAH2-Wz=Sjf0VnMDQW3PX0BsjH1h2ckBLqih3vS4WktxGhZtSmw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 9, 2017 at 7:58 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> I think I have this sorted out. What I don't understand, however, is
> why varstr_abbrev_convert() makes a point of looping until the result of
> strxfrm() fits into the output buffer (buf2), when we only need 8 bytes,
> and we throw away the rest later. Wouldn't it work to just request 8 bytes?
Maybe. We do that because strxfrm() is not required by the standard to
produce well defined contents for the buffer when the return value
indicates that it didn't fit entirely. This is a standard idiom, I
think.
> If there is a problem with just requesting 8 bytes, then I'm wondering
> how this would affect the ICU code branch.
This must be fine with ICU's ucol_nextSortKeyPart(), because it is
designed for the express purpose of producing only a few bytes of the
final blob at a time.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-02-09 18:06:47 | Re: Parameterization of partial path |
| Previous Message | Antonin Houska | 2017-02-09 17:36:39 | Parameterization of partial path |