Re: Odd usage of errmsg_internal in bufmgr.c - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Odd usage of errmsg_internal in bufmgr.c
Date
Msg-id aY4Jqm1LcanN7PgH@alap3.anarazel.de
Whole thread Raw
In response to Re: Odd usage of errmsg_internal in bufmgr.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Odd usage of errmsg_internal in bufmgr.c
List pgsql-hackers
Hi,

On 2026-02-11 22:13:24 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2026-02-11 20:34:50 -0500, Tom Lane wrote:
> >> I agree that that isn't great code, but what I don't like about it
> >> is the separation between where the format string is defined and
> >> where it is used.  It'd be very easy for the %-escapes to get out of
> >> sync with the types of the actual parameters, and if they did, the
> >> compiler would not warn you.  I think we ought to try to recast this
> >> into the normal usage pattern where the format is literal within the
> >> errmsg call.  I see the comment about avoiding code duplication, but
> >> to my mind this is a terrible solution.
> 
> > The amount of code duplication it avoids is rather substantial.
> 
> Really?  By my count it's strictly fewer lines to do it the
> straightforward way.  Yes, I'm counting removal of the comments
> defending doing it in the convoluted way, but on the other hand the
> attached patch adds quite a few extra line breaks for readability,
> and still comes out 4 lines shorter.  Not to mention less fragile.
> I do not see a reason why the existing code is good.

I think the code after the proposed change is considerably harder to read.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Next
From: Bertrand Drouvot
Date:
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view