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

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Mark Dilger" <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: "Postgres hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Andreas Karlsson" <andreas(at)proxel(dot)se>, "David Fetter" <david(at)fetter(dot)org>
Subject: Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]
Date: 2021-03-06 03:25:22
Message-ID: cb523657-2467-4ba2-92fa-b4030e8a1a08@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 5, 2021, at 20:46, Joel Jacobson wrote:
> My conclusion is that we should use setof int4range[] as the return value for regexp_positions().

If acceptable by the project, it be even nicer if we could just return the suggested composite type.

I don't see any existing catalog functions returning composite types though?
Is this due to some policy of not wanting composite types as return values for built-ins or just a coincidence?

Example on regexp_positions -> setof range[]
where range is:

CREATE TYPE range AS (start int8, stop int8);

SELECT regexp_positions('foObARbEqUEbAz', $re$(?=beque)$re$, 'i');
regexp_positions
------------------
{"(6,6)"}
(1 row)

SELECT r FROM regexp_positions('foobarbequebazilbarfbonk', $re$(b[^b]+)(b[^b]+)$re$, 'g') AS r;
r
-----------------------
{"(3,6)","(6,11)"}
{"(11,16)","(16,20)"}
(2 rows)

SELECT r[1].*, r[2].* FROM regexp_positions('foobarbequebazilbarfbonk', $re$(b[^b]+)(b[^b]+)$re$, 'g') AS r;
start | stop | start | stop
-------+------+-------+------
3 | 6 | 6 | 11
11 | 16 | 16 | 20
(2 rows)

SELECT r[1].* FROM regexp_positions('','^','g') AS r;
start | stop
-------+------
0 | 0
(1 row)

Thoughts?

/Joel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-03-06 04:06:12 Re: Add client connection check during the execution of the query
Previous Message Kohei KaiGai 2021-03-06 03:19:45 Re: contrib/cube - binary input/output handlers