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@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Embrace your flaws. They make you human, rather than perfect,
which you will never be.