Re: perltidy version - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: perltidy version
Date
Msg-id CABUevEyW9P_WBfCDwowcC9yC9J58-1vt8jqoR0_4AYTTNPh8iw@mail.gmail.com
Whole thread Raw
In response to Re: perltidy version  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: perltidy version
Re: perltidy version
List pgsql-hackers


On Fri, Mar 2, 2018 at 3:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Magnus Hagander wrote:
>> In that case, we should at least update our instructions for how to install
>> it. But that's definitely a better option than hosting our own copy.

> But surely the idea of updating the version to use should be considered
> further?  Maybe they have even improved the output ;-)  Has anyone
> looked?

+1.  We're not that far away from it being time to run pgindent/perltidy,
so now would be a good time to consider whether we like a newer version's
result better.

If we do decide to stick on the old version, then yes, improve the
pointer.

For example, Debian ships with 20140328, which produces the attached diff. I'm not sure if we want to go to whatever is a "common version on most platforms" today, or just "whatever is latest" if we do upgrade. AFAICT RHEL 7 seems to be on 20121207, RHEL 6 on 20090616. And in Ubuntu, 14.04 has 20120701, 16.04 has 20140328, and current devel has 20140328. In general there seems to be very little overlap there, except Debian and Ubuntu covers the same versions.

(Note that this diff is against HEAD -- it's possible a perltidy run with the current version would also generate a diff, I have not compared them to each other)

--
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: perltidy version
Next
From: Pierre Ducroquet
Date:
Subject: Re: ALTER TABLE does not check for column existence before starting operations