From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Noah Misch <noah@leadboat.com>, Bruce Momjian <bruce@momjian.us>,
        Jelte Fennema <postgres@jeltef.nl>,
 Andres Freund <andres@anarazel.de>,
        Peter Geoghegan <pg@bowt.ie>, Magnus Hagander <magnus@hagander.net>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Stephen Frost <sfrost@snowman.net>, Jesse Zhang <sbjesse@gmail.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: run pgindent on a regular basis / scripted manner
In-reply-to: <1215f2de-3c49-eb3a-e62b-da1c05cb51db@dunslane.net>
References: <20230123011002.fzcaa3krql3mqsfn@awork3.anarazel.de>
 <1509591.1674437376@sss.pgh.pa.us> <1608158.1674486546@sss.pgh.pa.us>
 <20230123173136.knn77pbuakhvjfgk@awork3.anarazel.de>
 <Y874Fh0q4mkk1s22@momjian.us>
 <CAGECzQTqoGHrePM_pwmhaM+J1XOygYjzFod4sf=PAt7J4A19Mw@mail.gmail.com>
 <2238493.1674572097@sss.pgh.pa.us> <Y9ArogF7c+UgPgq9@momjian.us>
 <20230129010603.GA1677550@rfd.leadboat.com> <Y9groc0Nyy7SOROy@momjian.us>
 <20230202062838.GA1832088@rfd.leadboat.com>
 <1477791.1675320029@sss.pgh.pa.us>
 <1215f2de-3c49-eb3a-e62b-da1c05cb51db@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Thu, 02 Feb 2023 09:06:36 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1534361.1675350058.1@sss.pgh.pa.us>
Date: Thu, 02 Feb 2023 10:00:58 -0500
Message-ID: <1534362.1675350058@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1534362.1675350058%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> Sure. There's probably some work that could still be done in this area
> too, such as making pgperltidy work similarly to how we've now make
> pgindent work.

Perhaps.  But before we commit to that, I'd like to see some tweaks to the
pgperltidy rules to make it less eager to revisit the formatting of lines
close to a change.  Its current behavior will induce a lot of "git blame"
noise if we apply these same procedures to Perl code.

(Should I mention reformat-dat-files?)

> There's also a question of timing. Possibly the best time would be when
> we next fork the tree.

Yeah.  We have generally not wanted to do a mass indent except
when there's a minimum amount of pending patches, ie after the last
CF of a cycle.  What I'd suggest is that we plan on doing a mass
indent and then switch over to the new rules, right after the March
CF closes.  That gives us a couple months to nail down and test out
the new procedures before they go live.

			regards, tom lane