Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gilles Darold <gilles(at)darold(dot)net>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>, er(at)xs4all(dot)nl, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace
Date: 2021-08-02 01:02:20
Message-ID: 1572284.1627866140@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> ... aside from the question of whether
> a too-large subexpression number should be an error or not.

Oh ... poking around some more, I noticed a very nearby precedent.
regexp_replace's replacement string can include \1 to \9 to insert
the substring matching the N'th parenthesized subexpression. But
if there is no such subexpression, you don't get an error, just
an empty insertion. So that seems like an argument for not
throwing an error for an out-of-range subexpr parameter.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2021-08-02 02:15:03 Re: Skipping logical replication transactions on subscriber side
Previous Message Nikolay Samokhvalov 2021-08-02 00:59:30 Re: amcheck verification for GiST and GIN