Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp

On Thu, Nov 27, 2025 at 10:28 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Thu, Nov 27, 2025 at 10:18:38AM +0900, Amit Langote wrote:
> > I’m fine with updating all core callers to use the new *_safe(... Node
> > *escontext) APIs all in one patch. However, we could consider keeping
> > the existing *_opt_overflow() functions as thin wrappers over the new
> > ones, to avoid breaking third-party extensions immediately for what is
> > primarily a refactoring change.
>
> Like 4246a977bad6, one point is to be able to make the internals of
> these functions leaner, by relying on the fact that the econtext node
> includes an error to let the callers of the functions decide what to
> do. If we keep some function wrappers as the ones we have now, this
> partially defeats the purpose of the change, which is to simplify
> in-core code at the end. This move also encourages users to switch to
> the new facility to be fed error reports generated by the in-core
> routines, meaning less duplication with error strings outside of the
> core code, hence less maintenance for out-of-core code.

Ok, I see, the idea is to encourage out-of-core code to move to the
new ErrorSaveContext-based handling, rather than keep wrappers around
just to ease the transition. IOW, we shouldn’t carry redundant code in
core once the new, simpler APIs exist. Sounds ok to me. Some
extension authors might grumble when their code stops compiling with
v19 though,only to find that the change was mostly stylistic ;-).

--
Thanks, Amit Langote