On Mon, Jan 30, 2023 at 03:42:09PM -0500, Bruce Momjian wrote:
> 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.
More important than frequency is how much old code changes. A new typedef
typically is an identifier not already appearing in the tree, so no old code
changes. A removed typedef typically no longer appears in the tree, so again
no old code changes. The tree can get those daily; they're harmless.
The push that adds or removes FooTypedef from the source code is in the best
position to react to any surprising indentation consequences of adding or
removing FooTypedef from typedefs.list. (Reactions could include choosing a
different typedef name or renaming incidental matches in older code.) Hence,
changing typedefs.list as frequently as it affects the code is less disruptive
than changing it once a year. The same applies to challenges like pgindent
wrecking a non-"/*----------" comment. Such breakage is hard to miss when
it's part of the push that crafts the comment; it's easier to miss in a bulk,
end-of-cycle pgindent.
Regarding the concern about a pre-receive hook blocking an emergency push, the
hook could approve every push where a string like "pgindent: no" appears in a
commit message within the push. You'd still want to make the tree clean
sometime the same week or so. It's cheap to provide a break-glass like that.
