Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsYwg-008TZA-Ny for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Oct 2023 01:32:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qsYwe-005jdu-Is for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Oct 2023 01:32:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsYwe-005jdl-9G for pgsql-hackers@lists.postgresql.org; Tue, 17 Oct 2023 01:32:28 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsYwb-001602-1J for pgsql-hackers@postgresql.org; Tue, 17 Oct 2023 01:32:28 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 39H1WCNn2626666; Mon, 16 Oct 2023 21:32:12 -0400 From: Tom Lane To: Peter Geoghegan cc: Andres Freund , Andrew Dunstan , Jelte Fennema , Michael Paquier , "shiy.fnst@fujitsu.com" , Robert Haas , Justin Pryzby , Noah Misch , Bruce Momjian , Magnus Hagander , Alvaro Herrera , Stephen Frost , Jesse Zhang , "pgsql-hackers@postgresql.org" , Peter Eisentraut Subject: Re: run pgindent on a regular basis / scripted manner In-reply-to: References: <30a72ba4-9ca4-15b5-db0f-0e68cba7ab26@dunslane.net> <1f594a4b-14c8-e159-b250-edf8a091320d@dunslane.net> <20230811212511.aih23qfthi24zhq4@awork3.anarazel.de> <338202.1691793002@sss.pgh.pa.us> <342032.1691794926@sss.pgh.pa.us> <8c4d8afb-cda1-299c-8011-f60cdaff3999@dunslane.net> <20230812211404.sydbwo2juu7vyhtg@awork3.anarazel.de> <530189.1691880417@sss.pgh.pa.us> <544112.1691886017@sss.pgh.pa.us> <2620572.1697503500@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Mon, 16 Oct 2023 18:22:51 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2626664.1697506332.1@sss.pgh.pa.us> Date: Mon, 16 Oct 2023 21:32:12 -0400 Message-ID: <2626665.1697506332@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Geoghegan writes: > My main objection to the new policy is that it's not quite clear what > process I should go through in order to be 100% confident that koel > won't start whining (short of waiting around for koel to whine). I > know how to run pgindent, of course, and haven't had any problems so > far...but it still seems quite haphazard. If we're going to make this > a hard rule, enforced on every commit, it should be dead easy to > comply with the rule. But it's *not* a hard rule --- we explicitly rejected mechanisms that would make it so (such as a precommit hook). I view "koel is unhappy" as something that you ought to clean up, but if you don't get to it for a day or three there's not much harm done. In theory koel might complain even if you'd locally gotten clean results from pgindent (as a consequence of skew in the typedef lists being used, for example). We've not seen cases of that so far though. Right now I think we just need to raise committers' awareness of this enough that they routinely run pgindent on the files they're touching. In the problem cases so far, they very clearly didn't. I don't see much point in worrying about second-order problems until that first-order problem is tamped down. regards, tom lane