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)  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: steve k
Дата:
Сообщение: Re: PQputCopyData dont signal error
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements