Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code
Дата
Msg-id CAB7nPqSDiNAyv8OkK3DXKkfd2tovSkaj1EhJW1DwRDnR7AypsA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
Ответы Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Fri, Dec 9, 2016 at 3:23 AM, Aleksander Alekseev
<a.alekseev@postgrespro.ru> wrote:
>> You could just change it to
>> if (str[strspn(str, " \t\n\r\f")] == '\0')
>> to mitigate calling strlen. It's safe to do so because strspn will
>> only return values from 0 to strlen(str).
>
>> [...] I have serious doubts that the "optimized" implementation
>> you propose is actually faster than a naive one; it may be slower, and
>> it's certainly longer and harder to understand/test.
>
> I would like to point out that I never said it's optimized. However I
> like the code Geoff proposed. It definitely doesn't make anything worse.
> I decided to keep pg_str_contansonly procedure (i.e. not to inline this
> code) for now. Code with strspn looks OK in a simple example. However in
> a concrete context it looks like a bad Perl code in ROT13 to me:

Looking at this patch, I am not sure that it is worth worrying about.
This is a receipt to make back-patching a bit more complicated, and it
makes the code more complicated to understand. So I would vote for
rejecting it and move on.

By the way, as you are placing this routine in src/common/, you may
want to consider updating the code in src/bin/ that use libpqcommon.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: 高增琦
Дата:
Сообщение: [HACKERS] Do we support using agg or window functions in delete statement?
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] Logical Replication WIP