Re: Add "format" target to make and ninja to run pgindent and pgperltidy - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add "format" target to make and ninja to run pgindent and pgperltidy
Date
Msg-id 1194980.1774623323@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add "format" target to make and ninja to run pgindent and pgperltidy  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Add "format" target to make and ninja to run pgindent and pgperltidy
List pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> v3-0007-pgindent-Integrate-pgperltidy-functionality-into-.patch
> v3-0008-pgindent-Add-easy-way-of-getting-perltidy.patch

> Still need to check these in more detail.  They will probably carry over 
> into PG20.

I still think that 0007 and 0008 need to be rejected, not postponed.
There is no cleanup that will make them acceptable in my eyes.

We did not start expecting commits to be pgindent-clean until pgindent
was integrated into our tree, providing (a) simple management of the
One True Version to use for each branch and (b) a trivial, safe way
to get that version.  We will never put perltidy into our tree, so
I don't see that it can ever be on the same footing as pgindent.
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.  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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Clean up NamedLWLockTranche stuff
Next
From: Peter Eisentraut
Date:
Subject: Re: Align tests for stored and virtual generated columns