> On 25 Nov 2025, at 17:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
>> On 2025-Nov-25, Daniel Gustafsson wrote:
>>> I routinely run pgperltidy src/ when hacking on things, and am greeted with
>>> lots of diffs like how pgindent runs used to be. Are there objections to
>>> applying the diffs we've accumulated so far with a .git-blame-ignore-revs
>>> update alongside it? Are there reasons not that I am missing?
>
>> None here. I tend to run pgperltidy on individual files so this is not
>> normally a problem for me, but I kinda dislike that our steady status is
>> not clean.
>
> While I've not got any great objection to running pgperltidy now,
> it seems like it'd be better if committers were all on the same page
> about this. My understanding of the current policy is that we'll
> keep the tree pgindent-clean on the fly, but worry about pgperltidy
> only once a year or so. Is there consensus for tightening that up?
I don't think there is, but I wouldn't mind if that was the case given how nice
it is to have a pgindent clean tree at all times.
>> Hmm, I wonder if you ran this with our documented version of perltidy.
>
> This sort of thing is why I'm hesitant. We didn't really dare expect
> committers to ensure pgindent cleanliness until we had that tool
> fully integrated in our tree, so that there was one true (and readily
> available) version to use. perltidy still fails that test AFAIK;
> you have to go looking for the agreed-on version.
..and since I managed to run it with the wrong version for the attached diff that
argument certainly does have merit (I now gave up on having two version
installed for $reasons and will settle on the postgres-mandated version for all
things).
Maybe this is best left alone for now and made into a topic for a committer
meeting at pgconf.dev?
--
Daniel Gustafsson
