Re: Add BF member koel-like indentation checks to SanityCheck CI

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 9, 2024 at 2:20 PM Tristan Partin <tristan(at)neon(dot)tech> wrote:
>>> I don't indent during most of development, and don't intend to start.

>> Could you expand on why you don't? I could understand as you're writing,
>> but I would think formatting on save, might be useful.

> John might have his own answer to this, but here's mine: it's a pain
> in the rear end. By the time I'm getting close to committing something
> I try to ensure that everything I'm posting is indented. But for early
> versions of work it adds a lot of paper-pushing with little
> corresponding benefit. I've been doing this long enough that my
> natural coding style is close to what pgindent would produce, but
> figuring out how many tab stops are needed after a variable name to
> make the result agree with pgindent's sentiments is not something I
> can do reliably.

FWIW, I rely on Emacs C mode during initial development, and while
it's not far off from what pgindent does there are certain things it
doesn't match (notably, alignment of variable declarations). I just
don't worry about that at that stage. Once I have something that's
turning over, I'll pgindent it before final review and showing it to
other people. That's mostly because I've been reading Postgres code
for so long that anything that isn't pgindented looks subtly wrong,
so reviewing it annoys my hindbrain. But trying to match pgindent's
rules by hand, in an editor that doesn't provide help for that, is not
worth the mental effort.

>> Perhaps the hardest thing to change is the culture of Postgres
>> development. If we can't all agree that we want formatted code, then
>> there is no point in anything that I discussed.

> I think we're basically committed to that at this point, and long have
> been.

Agreed. What's at stake here is not whether the final product will
be pgindented, but when that happens and who's responsible for making
it happen. We're trying to switch from "fix it once a year or so"
to "make sure it's right at the point of commit", which is a problem
for committers who up to now weren't in the habit of automatically
pgindenting. I don't think it's time to give up on the project of
changing those habits; and if we do give up, the answer surely must
not be to push the problem further upstream. Occasional contributors
are even less likely to be able to cope with this.

In short, I don't think that putting this into CI is the answer.
Putting it into committers' standard workflow is a better idea,
if we can get all the committers on board with that.

regards, tom lane