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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: 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-02 04:16:34
Message-ID: aLZvomRLvl1icq0s@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 01, 2025 at 12:21:18PM +0100, Dean Rasheed wrote:
> On Mon, 1 Sept 2025 at 10:36, Amul Sul <sulamul(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-09-02 04:27:16 Re: Orphan page in _bt_split
Previous Message David G. Johnston 2025-09-02 03:53:34 Re: SQL:2023 JSON simplified accessor support