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

On Wed, Nov 26, 2025 at 5:41 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Wed, Nov 26, 2025 at 8:43 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > On Wed, Nov 26, 2025 at 03:09:25PM +0530, Amul Sul wrote:
> > > This continues the previous refactoring commit [1] where we adopted
> > > soft error reporting for some numeric functions. This patch applies
> > > the same pattern to the date/timestamp function. The change ensures
> > > consistency by utilizing the existing soft error reporting
> > > infrastructure.
> >
> > Thanks for continuing this work.
>
> +1

Thank you both for taking a look at the patch.

>
> I see that Michael has now noticed this, I was looking at this earlier
> today and thought of a couple of nitpicky things to share:
>
> * The rename from *_opt_overflow to *_overflow_safe could be made a
> separate patch (say 0002), so it can be discussed separately. For
> example, whether to keep the old *_opt_overflow variants for backward
> compatibility since they’re exported and possibly used by extensions.
>

I am probably okay with this, but it is up to the committer. In the
previous commit, however, we performed a rename within the same
commit. IIUC, the extensions are expected to be updated with respect
to the major release

> * Maybe it's just me, but several function comments (for example
> around date2timestamptz_overflow_safe()) lost detailed explanations of
> overflow behavior. It’d be better to preserve those specifics and only
> adjust the wording to describe how errors are reported via escontext:
>

The previous comments are no longer relevant now that we are utilizing
the established error-safe infrastructure, but, I would think more on
this later since I am out of time today.

Regards,
Amul