parens cleanup
Some ereport calls have excess sets of parentheses. patch 0001 removes
the ones I found in a very quick grep.
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.
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.)
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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
On Wed, Jan 29, 2020 at 04:47:19PM -0500, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
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 ...
+1.
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 there 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.
I am not sure that this is worth a back-patch.
--
Michael
Thanks both for looking! I have pushed those, removing the zic.c
changes.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services