Date: Fri, 20 Mar 2020 11:42:02 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>,
	Amit Kapila <amit.kapila16@gmail.com>,
	Michael Paquier <michael@paquier.xyz>,
	Julien Rouhaud <rjuju123@gmail.com>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Missing errcode() in ereport
Message-ID: <20200320144202.GA25565@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9966.1584671550@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Mar-19, Tom Lane wrote:

> I think the key decision we'd have to make to move forward on this
> is to decide whether it's still project style to prefer the extra
> parens, or whether we want new code to do without them going
> forward.  If we don't want to risk requiring __VA_ARGS__ for the
> old branches then I'd vote in favor of keeping the parens as
> preferred style, at least till v11 is out of support.  If we do
> change that in the back branches then there'd be reason to prefer
> to go without parens.  New coders might still be confused about
> why there are all these calls with the useless parens, though.

It seems fine to accept new code in pg14 without the extra parens.  All
existing committers are (or should be) used to the style with the
parens, so it's unlikely that we'll mess up when backpatching bugfixes;
and even if we do, the buildfarm would alert us to that soon enough.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services