Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id 23898.1396297849@sss.pgh.pa.us
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)
List 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 by date:

Previous
From: steve k
Date:
Subject: Re: PQputCopyData dont signal error
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements