Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pLw9A-0004eI-4S for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Jan 2023 01:06:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pLw97-0006L1-EV for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Jan 2023 01:06:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pLw96-0006Ib-US for pgsql-hackers@lists.postgresql.org; Sun, 29 Jan 2023 01:06:13 +0000 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pLw91-0007p5-CB for pgsql-hackers@postgresql.org; Sun, 29 Jan 2023 01:06:11 +0000 Received: by mail-ot1-x335.google.com with SMTP id r17-20020a056830449100b0068bb088317aso1737643otv.12 for ; Sat, 28 Jan 2023 17:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=UMY0potv6FWOfLZ1WgnSXUjIDpNhX13ALAvSdToCeUk=; b=Wh/4USc/NXjMnjedx6mLZekK5kt3TPV30mraUEkfWna95KvAWDKzqd1tPoHBn4jShY vFmOJ85fOLLIAPUglFblrNvzaXxJZQq5HIoWAGnsstYB9ShY2P2TC0GPk+L1XcgUE7H6 TvCfcvI8qfma278djCjXbSX006z8GzIowhm4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UMY0potv6FWOfLZ1WgnSXUjIDpNhX13ALAvSdToCeUk=; b=yTKQfbpI8lUMBKTTEQx8uu7lXbmgChgtGtBYb6TrFeSXIDJrSz4Pr4H1rzkI/9InLp KddGoqUrjwhU7lRqOWJLnjwP7tQaMvsOWm+jSjhx4GgFfTOVjrN4j53UssZ04HoCRkdL LSxQEOEVDf+np3VW2xW+CKl8+DtuCQpyGQiG6trJ8JJqsdl/ftOQkQQgnbPm3LgYRg3H AVbRo4XsJImBBijJegnkajceAcnoQAvswrWunxawEPOTaBr4aFZqvbRqB4JgLmIeVAkz GHktTUYWHAIZakFBrZO77mwkrvnnfM1msb6NTdy/2MPc9dfbONaRfay6Vd4s9ALnmZQD j//w== X-Gm-Message-State: AFqh2kpYL+LyPfXzJqVpoJVMAQcmgEElg70hIpnx+b2ItzXcKbtrH0tt iEgVmR9KyZGEn40FrlQSd0hGp2Yzw+bSLh69 X-Google-Smtp-Source: AMrXdXueFjd4R0+003cxfHLwrX/bVGh3HjIcbj+ag+TFHv1uFlda0qBU2yIQuc3LlbZhTYhxHBYiKA== X-Received: by 2002:a05:6830:40c9:b0:661:dfeb:ea33 with SMTP id h9-20020a05683040c900b00661dfebea33mr22817178otu.24.1674954366280; Sat, 28 Jan 2023 17:06:06 -0800 (PST) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id h19-20020a056830035300b0068bbaf7a1b0sm1406304ote.34.2023.01.28.17.06.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2023 17:06:05 -0800 (PST) Date: Sat, 28 Jan 2023 17:06:03 -0800 From: Noah Misch To: Bruce Momjian Cc: Tom Lane , Jelte Fennema , Andres Freund , Peter Geoghegan , Magnus Hagander , Alvaro Herrera , Stephen Frost , Jesse Zhang , PostgreSQL-development Subject: Re: run pgindent on a regular basis / scripted manner Message-ID: <20230129010603.GA1677550@rfd.leadboat.com> References: <20230123001518.6hxyiczhn4kadvmf@awork3.anarazel.de> <1502504.1674433722@sss.pgh.pa.us> <20230123011002.fzcaa3krql3mqsfn@awork3.anarazel.de> <1509591.1674437376@sss.pgh.pa.us> <1608158.1674486546@sss.pgh.pa.us> <20230123173136.knn77pbuakhvjfgk@awork3.anarazel.de> <2238493.1674572097@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 24, 2023 at 02:04:02PM -0500, Bruce Momjian wrote: > On Tue, Jan 24, 2023 at 09:54:57AM -0500, Tom Lane wrote: > > As another example, the mechanisms we use to create the typedefs list > > in the first place are pretty squishy/leaky: they depend on which > > buildfarm animals are running the typedef-generation step, and on > > whether anything's broken lately in that code --- which happens on > > a fairly regular basis (eg [1]). Maybe that could be improved, > > but I don't see an easy way to capture the set of system-defined > > typedefs that are in use on platforms other than your own. I > > definitely do not want to go over to hand maintenance of that list. > > As I now understand it, we would need to standardize on a typedef list > at the beginning of each major development cycle, and then only allow > additions, Not to my knowledge. There's no particular obstacle to updating the list more frequently or removing entries. > and the addition would have to include any pgindent affects > of the addition. Yes, a hook intended to enforce pgindent cleanliness should run tree-wide pgindent when the given commit(s) change the typedef list. typedef list changes essentially become another kind of refactoring that can yield merge conflicts. If your commit passed the pgindent check, rebasing it onto a new typedefs list may require further indentation changes. New typedefs don't tend to change a lot of old code, so I would expect this sort of conflict to be minor, compared to all the other sources of conflicts.