Re: B-Tree support function number 3 (strxfrm() optimization)
От | Robert Haas |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CA+TgmoZxsQzDJXJE-CgdGTSZO=7Xw_k2ukvemOdfcArbg2veVA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
|
Список | pgsql-hackers |
On Thu, Aug 7, 2014 at 3:15 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Aug 6, 2014 at 7:18 PM, Peter Geoghegan <pg@heroku.com> wrote: >> On Wed, Aug 6, 2014 at 1:11 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> I've committed the patch I posted yesterday. I did not see a good >>> reason to meld that together in a single commit with the first of the >>> patches you posted; I'll leave you to revise that patch to conform >>> with this approach. >> >> Okay. Attached is the same patch set, rebased on top on your commit >> with appropriate amendments. > > Two things: > > + * result. Also, since strxfrm()/strcoll() require > NULL-terminated inputs, > > In my original patch, I wrote NUL, as in the NUL character. You've > changed it to NULL, but the original was correct. NULL is a pointer > value that is not relevant here; the character with value 0 is NUL. Gah. Hit send to soon. Also, as much as I'd prefer to avoid relitigating the absolutely stupid debate about how to expand the buffers, this is no good: + tss->buflen1 = Max(len1 + 1, tss->buflen1 * 2); If the first expansion is for a string >512MB and the second string is longer than the first, this will exceed MaxAllocSize and error out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: