Re: Refactoring: Use soft error reporting for *_opt_error functions

On Wed, Sep 03, 2025 at 10:41:14PM +0800, jian he wrote:
> would any extensions using these functions (such as
> numeric_int4_opt_error) may encounter upgrade compatibility issues in
> the future?

That would be also the point, so as callers are made aware of these
"upgraded" versions.

I have found one call outside of core here, so the practive is rare,
so doing the switch does not worry me much at the end:
https://github.com/siilike/postgresql-vpack

pg_lsn_in_internal() was worrying me a little bit more, because it
could impact backend-side code that wants to parse LSN strings with
the extra error handling, like potentially some HA tools, but looking
around I am just seeing references based on forked code of the core
repository. There's no way to know about closed source code, of
course, but I'm not going to qualify that as something that's worth
the cost of a compatibility layer with equivalent macros.

+ * Internal version of numeric_add() supports "soft" error reporting.

These comments still read incorrect to me (no point in quoting the
soft part, incorrect grammar). I'd suggest the following wording,
applied to all the new functions:
"Internal version of xxx_safe with support for soft error reporting."

I'd be pretty much OK with this version of the patch, plus a few
tweaks.

Dean, you have commented on this patch before me and the numeric code
is something you have touched more than me lately (the LSN part is
tainted with my fingerprints, but it's minimal here). Would you
prefer handle this patch yourself? I'm OK to perform a final lookup
of it for commit, just won't get in your way if you have been looking
at it seriously.
--
Michael