On Wed, Jan 11, 2017 at 4:50 PM, Michael Paquier
wrote:
> 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.
On Fri, Dec 9, 2016 at 3:23 AM, Aleksander Alekseev
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 "opti
Tom, Geoff,
Thanks for your feedback! Here is version 2 of this patch.
> 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 th
Aleksander Alekseev writes:
> How about rewriting such a code like this?
> if (pg_str_containsonly(str, " \t\n\r\f"))
Function name seems weirdly spelled. Also, I believe that in nearly all
use-cases the number of data characters that would typically be examined
is small, so I have serious doubt
On 8 December 2016 at 15:54, Aleksander Alekseev
wrote:
> Hi.
>
> I noticed that there is a lot of repeating code like this:
>
> ```
> if (strspn(str, " \t\n\r\f") == strlen(str))
> ```
>
> I personally don't find it particularly readable, not mentioning that
> traversing a string twice doesn't lo