Re: replace strtok()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replace strtok()
Date: 2024-06-24 12:57:27
Message-ID: 38483d31-457f-4e97-abe5-e0d29bf571d9@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24.06.24 02:34, Michael Paquier wrote:
> On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote:
>> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
>>> On 18.06.24 13:43, Ranier Vilela wrote:
>>>> I found another implementation of strsep, it seems lighter to me.
>>>> I will attach it for consideration, however, I have not done any testing.
>>
>>> Yeah, surely there are many possible implementations. I'm thinking,
>>> since we already took other str*() functions from OpenBSD, it makes
>>> sense to do this here as well, so we have only one source to deal with.
>>
>> Why not use strpbrk? That's equally thread-safe, it's been there
>> since C89, and it doesn't have the problem that you can't find out
>> which of the delimiter characters was found.
>
> Yeah, strpbrk() has been used in the tree as far as 2003 without any
> port/ implementation.

The existing uses of strpbrk() are really just checking whether some
characters exist in a string, more like an enhanced strchr(). I don't
see any uses for tokenizing a string like strtok() or strsep() would do.
I think that would look quite cumbersome. So I think a simpler and
more convenient abstraction like strsep() would still be worthwhile.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shlok Kyal 2024-06-24 12:57:33 Re: Pgoutput not capturing the generated columns
Previous Message Shlok Kyal 2024-06-24 12:56:03 Re: Pgoutput not capturing the generated columns