From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: perlcritic and perltidy |
Date: | 2018-05-08 12:11:47 |
Message-ID: | 20180508121147.GJ27724@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Michael Paquier (michael(at)paquier(dot)xyz) wrote:
> On Sun, May 06, 2018 at 09:14:06PM -0400, Stephen Frost wrote:
> > While I appreciate the support, I'm not sure that you're actually
> > agreeing with me.. I was arguing that braces should be on their own
> > line and therefore there would be a new line for the brace.
> > Specifically, when moving lines between hashes, it's annoying to have to
> > also worry about if the line being copied/moved has braces at the end or
> > not- much easier if they don't and the braces are on their own line.
>
> I should have read that twice. Yes we are not on the same line. Even
> if a brace is on a different line, per your argument it would still be
> nicer to add a comma at the end of each last element of a hash or an
> array, which is what you have done in the tests of pg_dump, but not
> something that the proposed patch does consistently. If the formatting
> is automated, the way chosen does not matter much, but the extra last
> comma should be consistently present as well?
Yes, that would be nice as well, as you'd be able to move entries around
more easily that way.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-05-08 12:31:12 | Re: perlcritic and perltidy |
Previous Message | Robert Haas | 2018-05-08 11:57:43 | Re: parallel.sgml for Gather with InitPlans |