Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 08 Jan 2024 19:51:58 -0500
Message-Id: <CY9RIU0NZPAE.XZOBLKSFPZZB@nmfay.com>
Cc: "Jim Nasby" <jim.nasby@gmail.com>, "Peter Eisentraut"
 <peter@eisentraut.org>, "PostgreSQL Hackers"
 <pgsql-hackers@lists.postgresql.org>
Subject: Re: add function argument names to regex* functions.
From: "Dian Fay" <di@nmfay.com>
To: "jian he" <jian.universality@gmail.com>
References: <CACJufxG3NFKKsh6x4fRLv8h3V-HvN4W5dA=zNKMxsNcDwOKang@mail.gmail.com> <b550243f-1bd2-4119-82e9-0f0abccc6434@eisentraut.org> <CACJufxHeyc34PMx6OnWb-xoaMtj1Yoax1rM+71zkwCynvmVwdg@mail.gmail.com> <CY3KI01TXYMD.3Q41WQ6U0NFEO@nmfay.com> <0eb3a5d7-75d8-4da5-9c88-a93deccdaa03@gmail.com> <CY5G4TAMVX32.23TH6LFF93ATZ@nmfay.com> <75129a34-14da-48aa-9906-42062fe78664@gmail.com> <CACJufxHBx+AHGVJocDSD-PbX0z32vJR9eEUhB+vsJHbjwnXNcg@mail.gmail.com> <CY8WQVZ0PK1B.19QRO61WBALCP@nmfay.com> <CACJufxHTw22kOmmDBpubmju9bfFhonEekwf0s6LGvysbnWEg9Q@mail.gmail.com>
In-Reply-To: <CACJufxHTw22kOmmDBpubmju9bfFhonEekwf0s6LGvysbnWEg9Q@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/CY9RIU0NZPAE.XZOBLKSFPZZB%40nmfay.com>
Precedence: bulk

On Mon Jan 8, 2024 at 9:26 AM EST, jian he wrote:
> On Mon, Jan 8, 2024 at 8:44=E2=80=AFAM Dian Fay <di@nmfay.com> wrote:
> > The `regexp_replace` summary in table 9.10 is mismatched and still
> > specifies the first parameter name as `string` instead of `source`.
> > Since all the other functions use `string`, should `regexp_replace` do
> > the same or is this a case where an established "standard" diverges?
>
> got it. Thanks for pointing it out.
>
> in functions-matching.html
> if I change <replaceable>source</replaceable> to
> <replaceable>string</replaceable> then
> there are no markup "string" and markup "string", it's kind of
> slightly confusing.
>
> So does the following refactored description of regexp_replace make sense=
:
>
>      The <replaceable>string</replaceable> is returned unchanged if
>      there is no match to the <replaceable>pattern</replaceable>.  If the=
re is a
>      match, the <replaceable>string</replaceable> is returned with the
>      <replaceable>replacement</replaceable> string substituted for the ma=
tching
>      substring.  The <replaceable>replacement</replaceable> string can co=
ntain
>      <literal>\</literal><replaceable>n</replaceable>, where
> <replaceable>n</replaceable> is 1
>      through 9, to indicate that the source substring matching the
>      <replaceable>n</replaceable>'th parenthesized subexpression of
> the pattern should be
>      inserted, and it can contain <literal>\&amp;</literal> to indicate t=
hat the
>      substring matching the entire pattern should be inserted.  Write
>      <literal>\\</literal> if you need to put a literal backslash in
> the replacement
>      text.

That change makes sense to me! I'll see about the section refactoring
after this lands.