> On 25 Nov 2025, at 17:00, Tom Lane <[email protected]> wrote: > > =?utf-8?Q?=C3=81lvaro?= Herrera <[email protected]> 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
