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 05:22:44
Message-ID: CAMsGm5fNjzXNY5PhKZOMUhPdi-2nAP9mQk-ohFJubHhZSg10Kg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> I find it strange two ranges of zero-length with different bounds are
> considered equal:
>
> SELECT '[7,7)'::int4range = '[8,8)'::int4range;
> ?column?
> ----------
> t
> (1 row)
>
> This seems like a bug to me. What am I missing here?
>
> Unless fixed, then the way I see it, I don't think we can use int4range[]
> for regexp_positions(),
> if we want to allow returning the positions for zero-length matches, which
> would be nice.
>

Ranges are treated as sets. As such equality is defined by membership.

That being said, I agree that there may be situations in which it would be
convenient to have empty ranges at specific locations. Doing this would
introduce numerous questions which would have to be resolved. For example,
where/when is the empty range resulting from an intersection operation?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-03-02 05:28:21 Re: repeated decoding of prepared transactions
Previous Message Ajin Cherian 2021-03-02 05:08:34 Re: repeated decoding of prepared transactions