From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: parens cleanup
In-reply-to: <20200129200401.GA6303@alvherre.pgsql>
References: <20200129200401.GA6303@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Wed, 29 Jan 2020 17:04:01 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5746.1580334439.1@sss.pgh.pa.us>
Date: Wed, 29 Jan 2020 16:47:19 -0500
Message-ID: <5747.1580334439@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Some ereport calls have excess sets of parentheses.  patch 0001 removes
> the ones I found in a very quick grep.

+1 ... kind of looks like somebody got this wrong long ago, and then
various people copied-and-pasted from a bad example.

> 0002 removes newlines immediately following parens.  These were
> previously useful because pgindent would move arguments further to the
> left so that the line would fit under 80 chars.  However, pgindent no
> longer does that, so the newlines are pointless and ugly.

+1 except for the changes in zic.c.  Those line breaks are following
the upstream code, so I'd just put them back in the next merge ...

> These being cosmetic cleanups, they're not intended for backpatch,
> though an argument could be made that doing that would save some future
> backpatching pain.  If ther are sufficient votes for that, I'm open to
> doing it.  (Of course, 0002 would not be backpatched further back than
> pg10, the first release that uses the "new" pgindent rules.)

Meh, -0.1 or so on back-patching.

			regards, tom lane