Horton

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

amul sul <sulamul@gmail.com>

View thread
From: Amul Sul <sulamul@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-26T13:01:03Z
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 →

  1. Update some timestamp[tz] functions to use soft-error reporting

  2. Switch some date/timestamp functions to use the soft error reporting

  3. Switch some numeric-related functions to use soft error reporting

On Wed, Nov 26, 2025 at 5:13 PM Michael Paquier <michael@paquier.xyz> wrote:
>
>
> Hmm.  Following the previous example you have quoted, I am wondering
> if we'd tweak the names a bit differently.  Rather than the
> popo_overflow_safe() pattern from your patch, I would choose a simpler
> popo_safe() as naming convention.  That would be also more consistent
> with the names applied to the refactored routines of 4246a977bad6.
>

The reason for this naming was to maintain consistency with the
function date2timestamp_no_overflow() in date.h. I am now uncertain
whether we should rename date2timestamp_no_overflow() as well to align
with the current change. I also lean towards popo_safe() as a naming
convention.

> -   result = date2timestamp_opt_overflow(val, &overflow);
> +   result = date2timestamp_overflow_safe(val, (Node *) &escontext);
>     /* We can ignore the overflow result, since result is useful as-is */
>
> In these cases, why don't you just pass NULL to the routines for the
> error context?  (Sorry, I don't have my eyes on the code now, but I
> recall that NULL should work as well, meaning the same as "ignore
> me".)

Won't that result in an error that we are trying to avoid?

Regards,
Amul