Re: Refactoring: Use soft error reporting for *_opt_error functions

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Amul Sul <sulamul(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Refactoring: Use soft error reporting for *_opt_error functions
Date: 2025-09-04 09:50:38
Message-ID: CAEZATCVeHvmd-bWZmrhPUUDXbmwrNP3FB=fXwtDkXQjQthvxew@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 4 Sept 2025 at 01:18, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> I'd be pretty much OK with this version of the patch, plus a few
> tweaks.

Agreed.

In numeric_div_safe():

+div_error:
+ ereturn(escontext, NULL,
+ errcode(ERRCODE_DIVISION_BY_ZERO),
+ errmsg("division by zero"));

I would make that label something more specific like "division_by_zero".

> Dean, you have commented on this patch before me and the numeric code
> is something you have touched more than me lately (the LSN part is
> tainted with my fingerprints, but it's minimal here). Would you
> prefer handle this patch yourself? I'm OK to perform a final lookup
> of it for commit, just won't get in your way if you have been looking
> at it seriously.

I don't mind. I haven't looked at it too closely, but I'm broadly
happy with it. I think any issues are probably now minor cosmetic
things, so if you've been looking in more detail and are happy to
commit it, then go ahead. Otherwise, I can take it if you prefer.

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2025-09-04 09:52:24 Re: MergeAppend could consider sorting cheapest child path
Previous Message Peter Eisentraut 2025-09-04 09:05:03 Re: Cannot find a working 64-bit integer type on Illumos