On Fri, 27 Mar 2026 at 15:55, Tom Lane <[email protected]> wrote: > We did not start expecting commits to be pgindent-clean until pgindent > was integrated into our tree
Merging these commits does not mean we force committers to run perltidy on every commit. That a completely separate discussion that is not worth having until after we make perltidy less of a pain to run. Even without forcing committers to run perltidy I think 0007 and 0008 are still beneficial. > The 0008 patch doesn't fix that, and in fact I think it would be > dangerous to even provide that script in our tree. It's a supply- > chain attack waiting to happen. I strongly disagree. Instead I think, our current pgindent README[1] is a supply-chain attack waiting to happen. Our pgindent README tells people to get a tar file from the CPAN website, but WITHOUT the signature checks that the script in 0008 includes. These added signature checks prevent it from being a supply chain risk. > Even if it were guaranteed 100% > secure, too many developers are subject to (perfectly reasonable) > corporate security policies that would look with disfavor on > unauthorized installation of Perl modules. I'd be curious to know which committer is not allowed to download and run a specific signature verified perl module, but is allowed to get the latest postgres source code from main. [1]: https://github.com/postgres/postgres/blob/9a9998163bda0d8c17d84ea22ced6a60f8018634/src/tools/pgindent/README#L18-L27 P.S. Reading your response, I cannot help but interpret it as an attempt to sidestep any future discussion about always running perltidy, by pre-emptively rejecting any and all improvements that would make perltidy easier to run.
