Re: add function argument names to regex* functions.

From: "Dian Fay" <di(at)nmfay(dot)com>
To: "jian he" <jian(dot)universality(at)gmail(dot)com>
Cc: "Jim Nasby" <jim(dot)nasby(at)gmail(dot)com>, "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: add function argument names to regex* functions.
Date: 2024-01-11 03:57:33
Message-ID: CYBKQ0JZDCGV.3BEEWXZOXCXUS@nmfay.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed Jan 10, 2024 at 9:18 AM EST, jian he wrote:
> On Tue, Jan 9, 2024 at 8:52 AM Dian Fay <di(at)nmfay(dot)com> wrote:
> >
> > On Mon Jan 8, 2024 at 9:26 AM EST, jian he wrote:
> > > On Mon, Jan 8, 2024 at 8:44 AM Dian Fay <di(at)nmfay(dot)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 there is a
> > > match, the <replaceable>string</replaceable> is returned with the
> > > <replaceable>replacement</replaceable> string substituted for the matching
> > > substring. The <replaceable>replacement</replaceable> string can contain
> > > <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 that 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.
>
> I put the changes into the new patch.

Sorry, I missed one minor issue with v2. The replacement on lines
6027-6028 of func.sgml (originally "`n` rows if there are `n` matches")
is not needed and could be more confusing since the `n` represents a
number, not an argument to `regexp_matches`. I've built v3 and gone over
everything else one more time and it looks good.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-01-11 04:02:00 Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows
Previous Message Michael Paquier 2024-01-11 03:45:12 Re: heavily contended lwlocks with long wait queues scale badly