| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Pgsql Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: The pgperltidy diffs in HEAD |
| Date: | 2025-11-25 15:49:32 |
| Message-ID: | 202511251509.p5lobd2476vn@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> Attached is the current output from pgperltidy, I haven't looked over it in
> detail but I am happy to take that on assuming it's not objected to.
Hmm, I wonder if you ran this with our documented version of perltidy.
I have vague memories of pgperltidy leaving the generate-lwlocknames.pl
script the way it is now, for example. But then, maybe the one who used
the wrong perltidy version is me.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-11-25 15:50:16 | Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent |
| Previous Message | Melanie Plageman | 2025-11-25 15:44:31 | Re: Buffer locking is special (hints, checksums, AIO writes) |