Re: [Proposal] Adding Log File Capability to pg_createsubscriber - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [Proposal] Adding Log File Capability to pg_createsubscriber
Date
Msg-id CAA4eK1JiAzaY7UYnya7uDhX-kAL1PrsOAxBtys7c35t4q4H3_A@mail.gmail.com
Whole thread
In response to Re: [Proposal] Adding Log File Capability to pg_createsubscriber  (Gyan Sreejith <gyan.sreejith@gmail.com>)
Responses Re: [Proposal] Adding Log File Capability to pg_createsubscriber
List pgsql-hackers
On Fri, Mar 20, 2026 at 10:30 PM Gyan Sreejith <gyan.sreejith@gmail.com> wrote:
>

0001:
=====
*
+static void pg_createsub_log(enum pg_log_level, enum pg_log_part,
+ const char *pg_restrict fmt,...)
+ pg_attribute_printf(3, 4);
+pg_noreturn static void pg_fatal(const char *pg_restrict fmt,...)
+ pg_attribute_printf(1, 2);

I see similar functions in other modules are named a bit differently.
For example, see report_manifest_error(), report_backup_error(),
report_fatal_error(). Then I see many other error reporting functions
named similarly in code, some examples are: report_invalid_record(),
report_invalid_page(), report_namespace_conflict(), and
report_recovery_conflict().

Based on the above information, can we consider renaming the above
functions to report_createsub_log() and report_createsub_fatal()?

Other than the above point, 0001 LGTM.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Next
From: Alexander Lakhin
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)