Re: Odd usage of errmsg_internal in bufmgr.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
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 03:13:24
Message-ID: 182837.1770866004@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

Attachment Content-Type Size
decomplicate-buffer_readv_report.patch text/x-diff 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2026-02-12 04:58:37 Re: refactor architecture-specific popcount code
Previous Message Tom Lane 2026-02-12 02:49:38 Re: Regression failures after changing PostgreSQL blocksize