Re: Odd usage of errmsg_internal in bufmgr.c

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Odd usage of errmsg_internal in bufmgr.c
Date: 2026-02-12 17:12:03
Message-ID: aY4Jqm1LcanN7PgH@alap3.anarazel.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-02-11 22:13:24 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-02-12 17:23:49 Re: pgsql: Introduce pg_shmem_allocations_numa view
Previous Message Robert Haas 2026-02-12 16:47:37 Re: Add 64-bit XIDs into PostgreSQL 15