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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Amit Langote <amitlangote09@gmail.com>

Cc: Amul Sul <sulamul@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-11-27T01:27:53Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Update some timestamp[tz] functions to use soft-error reporting
- 713d9a847e64 19 (unreleased) landed
Switch some date/timestamp functions to use the soft error reporting
- d03668ea0566 19 (unreleased) landed
Switch some numeric-related functions to use soft error reporting
- 4246a977bad6 19 (unreleased) cited

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.
--
Michael