Re: B-Tree support function number 3 (strxfrm() optimization)
От | Tom Lane |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | 23898.1396297849@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
|
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes: > On Mon, Mar 31, 2014 at 8:08 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> Note the last sentence. To avoid the undefined behavior, you have to pass a >> buffer that's large enough to hold the whole result, and then truncate the >> result. > I was working off the glibc documentation, which says: > "The return value is the length of the entire transformed string. This > value is not affected by the value of size, but if it is greater or > equal than size, it means that the transformed string did not entirely > fit in the array to. In this case, only as much of the string as > actually fits was stored. To get the whole transformed string, call > strxfrm again with a bigger output array." > It looks like this may be a glibc-ism. Possibly worth noting is that on my RHEL6 and Fedora machines, "man strxfrm" says the same thing as the POSIX spec. Likewise on OS X. I don't think we can rely on what you suggest. regards, tom lane
В списке pgsql-hackers по дате отправления: