Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace - Mailing list pgsql-hackers

From Gilles Darold
Subject Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace
Date
Msg-id 57cdabdb-4d63-e6ee-66ee-1ffc462e7149@darold.net
Whole thread Raw
In response to Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace
List pgsql-hackers
Le 03/08/2021 à 15:39, Tom Lane a écrit :
> Erik Rijkers <er@xs4all.nl> writes:
>> On 8/3/21 1:26 PM, Gilles Darold wrote:
>>> Le 03/08/2021 à 11:45, Gilles Darold a écrit :
>>>> Actually I just found that the regexp_like() function doesn't support
>>>> the start parameter which is something we should support. I saw that
>>>> Oracle do not support it but DB2 does and I think we should also
>>>> support it. I will post a new version of the patch once it is done.
>> +1
>> I for one am in favor of this 'start'-argument addition.  Slightly
>> harder usage, but more precise manipulation.
> As I said upthread, I am *not* in favor of making those DB2 additions.
> We do not need to create ambiguities around those functions like the
> one we have for regexp_replace.  If Oracle doesn't have those options,
> why do we need them?


Sorry I have missed that, but I'm fine with this implemenation so let's 
keep the v6 version of the patch and drop this one.

-- 
Gilles Darold




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Use generation context to speed up tuplesorts
Next
From: Robert Haas
Date:
Subject: Re: when the startup process doesn't (logging startup delays)