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

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Joel Jacobson <joel(at)compiler(dot)org>
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>
Subject: Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]
Date: 2021-03-02 14:05:34
Message-ID: CAMsGm5cai7jJWqfSqMGNvGkkEsZEvPJvaEv1B5hcy=PoWRCY5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2 Mar 2021 at 08:58, Joel Jacobson <joel(at)compiler(dot)org> wrote:

> If we stipulate that the result array will be in order, then you still
> don’t have the exact location of empty matches but you do at least have
> where they are relative to non-empty matches.
>
>
> This part I didn't fully understand. Can you please provide some example
> on this?
>

Suppose the match results are:

[4,8)
[10,10)
[13,16)
[20,20)
[24,24)

Then this gets turned into:

[4,8)
empty
[13,16)
empty
empty

So you know that there are non-empty matches from 4-8 and 13-16, plus an
empty match between them and two empty matches at the end. Given that all
empty strings are identical, I think it's only in pretty rare circumstances
where you need to know exactly where the empty matches are; it would have
to be a matter of identifying empty matches immediately before or after a
specific pattern; in which case I suspect it would usually be just as easy
to match the pattern itself directly.

Does this help?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2021-03-02 14:08:43 Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.
Previous Message Joel Jacobson 2021-03-02 13:58:16 Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]