Re: run pgindent on a regular basis / scripted manner

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jelte Fennema <postgres(at)jeltef(dot)nl>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie>, Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Jesse Zhang <sbjesse(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: run pgindent on a regular basis / scripted manner
Date: 2023-01-30 20:42:09
Message-ID: Y9groc0Nyy7SOROy@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 28, 2023 at 05:06:03PM -0800, Noah Misch wrote:
> 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.

We would need to re-pgindent the tree each time, I think, which would
cause disruption if we did it too frequently.

> > 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.

Agreed.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Embrace your flaws. They make you human, rather than perfect,
which you will never be.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2023-01-30 20:57:34 Re: heapgettup() with NoMovementScanDirection unused in core?
Previous Message Robert Haas 2023-01-30 20:32:34 Re: Non-superuser subscription owners