Re: Refactoring: Use soft error reporting for *_opt_error functions
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Amul Sul <sulamul@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-02T04:16:34Z
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 →
-
Fix two comments in numeric.c
- 0c7f10302820 19 (unreleased) landed
-
Switch some numeric-related functions to use soft error reporting
- 4246a977bad6 19 (unreleased) landed
-
Change pg_lsn_in_internal() to use soft error reporting
- ae453120085f 19 (unreleased) landed
On Mon, Sep 01, 2025 at 12:21:18PM +0100, Dean Rasheed wrote: > On Mon, 1 Sept 2025 at 10:36, Amul Sul <sulamul@gmail.com> wrote: >> I believe we should update all *_opt_error functions to use the new >> soft error reporting infrastructure instead of boolean flags -- did >> the same in the attached patch. I am not sure if this patch should be >> part of that thread[1]. It's a significant improvement in itself, as >> it would make the code more compact and consistent. Handling that as a separate patch seems OK here. Thanks for caring. > Agreed. That does look neater. Yep. More consistent. +/* forward declarations to avoid node.h include */ +typedef struct Node Node; s/declarations/declaration/. Singular required, only one declaration. Looking at the surroundings, would it make sense to do the same for pg_lsn_in_internal()? It requires a safe fallback when parsing the LSN from the recovery_target_lsn GUC. -- Michael