Re: perltidy version

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: perltidy version
Дата
Msg-id CABUevEyW9P_WBfCDwowcC9yC9J58-1vt8jqoR0_4AYTTNPh8iw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: perltidy version  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: perltidy version  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: perltidy version  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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)

--
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: perltidy version
Следующее
От: Pierre Ducroquet
Дата:
Сообщение: Re: ALTER TABLE does not check for column existence before starting operations