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