Re: run pgindent on a regular basis / scripted manner

But I do think this discussion about other formatting tools
is distracting from the main pain point I wanted to discuss:
our current formatting tool is not run consistently enough.
The only thing that another tool will change in this
regard is that there is no need to update typedefs.list.
It doesn't seem like that's such a significant difference
that it would change the solution to the first problem.

When reading the emails in this discussion from 2 years ago
it seems like the respondents wouldn't mind updating the
typedefs.list manually. And proposed approach number 3
seemed to have support overall, i.e. fail a push to master
when pgindent was not run on the new commit. Would
it make sense to simply try that approach and see if
there's any big issues with it?

> (Another problem here is that there's a sizable subset of committers
> who clearly just don't care, and I'm not sure we can convince them to.)

My guess would be that the main reason is simply
because committers forget it sometimes because
there's no automation complaining about it.

On Sun, 22 Jan 2023 at 18:20, Jelte Fennema <postgres@jeltef.nl> wrote:
>
> > But so far I haven't seen one that can make that
> > column be column +12.
>
> Thanks for clarifying what the current variable declaration indention
> rule is. Indeed neither uncrustify or clang-format seem to support
> that. Getting uncrustify to support it might not be too difficult, but
> the question remains if we even want that.
>
> > But switching away from that intermixed with a lot of other changes isn't going to be fun.
>
> I don't think the amount of pain is really much lower if we reformat
> 10,000 or 300,000 lines of code, without automation both would be
> quite painful. But the git commands I shared in my previous email
> should alleviate most of that pain.
>
> > I don't have a problem with the current pgindent alignment of function
> > parameters, so not sure what you mean about that.
>
> Function parameter alignment is fine with pgindent imho, but this +12
> column variable declaration thing I personally think is quite weird.
>
> > Really? I have been using 14, which is quite recent. Did you just
> > figure this out recently? If this is true, then it's certainly
> > discouraging.
>
> It seems this was due to my Ubuntu 22.04 install having clang-format
> 14.0.0. After
> updating it to 14.0.6 by using the official llvm provided packages, I
> don't have this
> issue on clang-format-14 anymore. To be clear this was an issue in alignment of
> variable declarations not function parameters.
>
> But I agree with Tom Lane that this makes clear that whatever tool we
> pick we'll need
> to pick a specific version, just like we do now with perltidy. And
> indeed I'm not sure
> how easy that is with clang. Installing a specific uncrustify version
> is pretty easy btw,
> the compilation from source is quite quick.