On Tue, Oct 14, 2025 at 12:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andrew Dunstan <andrew@dunslane.net> writes:
> > I'm late to the party on this, but I wonder if it wouldn't be better to
> > use a type-neutral parameter name here, like "source", which could cover
> > all these cases, instead of "string", "bytes", etc.
>
> +1 for that idea. As Jian notes, we'd need to make the docs match,
> but I think that this would be an improvement across the board.
> Parameter names like "string" don't convey much information.
>
hi.
regexp_count(string text, pattern text, start integer, flags text)
regexp_instr(string text, pattern text, start integer, "N" integer,
endoption integer, flags text, subexpr integer)
regexp_like(string text, pattern text, flags text)
regexp_match(string text, pattern text, flags text)
regexp_matches (string text, pattern text, flags text)
regexp_replace(string text, pattern text, replacement text, start
integer, "N" integer, flags text)
regexp_split_to_table(string text, pattern text, flags text)
regexp_substr(string text, pattern text, start integer, "N" integer,
flags text, subexpr integer)
For the above regex function, other function argument names look good
to me except the "string".
Do we also need to rename these function's first argument from "string" to
"source"? This would be a compatibility break, but if we do it now, it would
only impact one release.
-------------------
rebased due to conflict by commit:
https://git.postgresql.org/cgit/postgresql.git/commit/?id=49d43faa835f3c6817be9fc0b98bec0d661c2587