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

From Michael Paquier
Subject Re: Refactoring: Use soft error reporting for *_opt_error functions
Date
Msg-id aLaczOzuVoBQeCOy@paquier.xyz
Whole thread Raw
In response to Re: Refactoring: Use soft error reporting for *_opt_error functions  (Amul Sul <sulamul@gmail.com>)
Responses Re: Refactoring: Use soft error reporting for *_opt_error functions
List pgsql-hackers
On Tue, Sep 02, 2025 at 12:40:25PM +0530, Amul Sul wrote:
> Just a quick question regarding the naming conventions. It looks like
> we have a choice between two options for consistency. Should we rename
> the pg_lsn_in_internal function by replacing "_internal" with "_safe",
> or should we rename all of the *_opt_error functions by replacing
> "_opt_error" with "_internal"?
>
> I would choose the latter option.

Applying "_safe" seems a bit more consistent to me, as per past
changes like ccff2d20ed96, also looking at the functions that are
given a ErrorSaveContext in input.  I am ready to believe that there
are not a lot of callers of the existing _opt_error() routines listed
in numeric.h, so a renaming may be better to let existing callers know
about the change.  These predate the introduction of the "_safe"
functions, introduced in 16d489b0fe05.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Srirama Kucherlapati
Date:
Subject: Concurrency Issue with pg_ctl causing processes to hang in PostgreSQL 15.12
Next
From: Shlok Kyal
Date:
Subject: Fix use of variable after pfree