Re: Remove useless arguments in ReadCheckpointRecord(). - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Remove useless arguments in ReadCheckpointRecord().
Date
Msg-id 20220726.094223.2244804802157747041.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Remove useless arguments in ReadCheckpointRecord().  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove useless arguments in ReadCheckpointRecord().
List pgsql-hackers
At Sun, 24 Jul 2022 22:40:16 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> > On 2022/07/22 17:31, Kyotaro Horiguchi wrote:
> >> I believed that it is recommended to move to the style not having the
> >> outmost parens.  That style has been introduced by e3a87b4991.
> 
> > I read the commit log, but I'm not sure yet if it's really recommended to remove extra parens even from the
existingcalls to errmsg(). Removing extra parens can interfere with back-patching of the changes around those errmsg(),
can'tit?
 
> 
> Right, so I wouldn't be in a hurry to change existing calls.  If you're
> editing an ereport call for some other reason, it's fine to remove the
> excess parens in it, because you're creating a backpatch hazard there
> anyway.  But otherwise, I think such changes are make-work in themselves
> and risk creating more make-work for somebody else later.

So, I meant to propose to remove extra parens for errmsg()'s where the
message string is edited.  Is it fine in that criteria?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Next
From: Lukas Fittl
Date:
Subject: Re: log_line_prefix: make it possible to add the search_path