Re: Refactoring: Use soft error reporting for *_opt_error functions - Mailing list pgsql-hackers

From Amul Sul
Subject Re: Refactoring: Use soft error reporting for *_opt_error functions
Date
Msg-id CAAJ_b94J9Lmi1F+oZC2ZkyET1WSdCi3=gO+z1FUFM8-zsL2+4g@mail.gmail.com
Whole thread Raw
In response to Re: Refactoring: Use soft error reporting for *_opt_error functions  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Refactoring: Use soft error reporting for *_opt_error functions
List pgsql-hackers
On Wed, Sep 3, 2025 at 1:04 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Wed, 3 Sept 2025 at 07:47, Michael Paquier <michael@paquier.xyz> wrote:
> >
> > The same error message is repeated twice.  How about using some gotos
> > and one single ereport instead of two?  The same can be said for
> > numeric_div_safe() and numeric_mod_safe(), for the division-by-0
> > messages.
>
> In numeric_div_safe() and numeric_mod_safe():
>
> -     * If "have_error" is provided, check for division by zero here
> +     * If "escontext" is provided, raise division by zero soft error here
>       */
> -    if (have_error && (arg2.ndigits == 0 || arg2.digits[0] == 0))
> -    {
> -        *have_error = true;
> -        return NULL;
> -    }
> +    if (escontext && (arg2.ndigits == 0 || arg2.digits[0] == 0))
> +        ereturn(escontext, NULL,
> +                errcode(ERRCODE_DIVISION_BY_ZERO),
> +                errmsg("division by zero"));
>
> This might as well now be made to check for division-by-zero even if
> escontext is NULL.

Agreed -- did the same in the attached version including the error
deduplication that Michael suggested.

Regards,
Amul

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_restore --no-policies should not restore policies' comment
Next
From: Ranier Vilela
Date:
Subject: Re: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c