Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "daniel(at)yesql(dot)se" <daniel(at)yesql(dot)se>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mark Dilger" <mark(dot)dilger(at)enterprisedb(dot)com>, "Postgres hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Andreas Karlsson" <andreas(at)proxel(dot)se>, "David Fetter" <david(at)fetter(dot)org>, "Gilles Darold" <gilles(at)darold(dot)net>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]
Date: 2021-09-12 13:54:15
Message-ID: 338b32ec-b0ad-46b1-864e-4c470aad5624@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 2, 2021, at 00:03, Daniel Gustafsson wrote:
> I can see value in a function like this one, and the API is AFAICT fairly
> aligned with what I as a user would expect it to be given what we already have.

Good to hear and thanks for looking at this patch.

I've fixed the problem due to the recent change in setup_regexp_matches(),
which added a new int parameter "start_search".
I pass 0 as start_search, which I think should give the same behaviour as before.

I also changed the assigned oid values in pg_proc.dat for the two new regexp_positions() catalog functions.

$ make check

=======================
All 209 tests passed.
=======================

/Joel

Attachment Content-Type Size
0005-regexp-positions.patch application/octet-stream 9.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-09-12 15:13:12 Re: Added schema level support for publication.
Previous Message Private Information Retrieval(PIR) 2021-09-12 13:02:44 Private Information Retrieval (PIR) as a C/C++ Aggregate Extension