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

On Tue Jan 9, 2024 at 2:49 PM CST, Robert Haas wrote:
> 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.

Interesting that you think this way. I generally setup format on save in
my editors and never think about things again. I agree that the indents
after variables is the hardest thing to internalize!

> > 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. Before koel started grumping, people would periodically pgindent
> particular files because if you wanted to indent your new patch, you
> had to run pgindent on the file and then back out the changes that
> were due to the preexisting file contents rather than your patch. That
> was maddening in its own way. The new system is annoying a slightly
> different set of people for a slightly different set of reasons, but
> everybody understands that in the end, it's all gonna get pgindented.

I've seen this in the git-blame-ignore-revs file. Good to know the
historical context.

> I also agree with you that the culture of Postgres development is hard
> to change. This is the only OSS project that I've ever worked on, and
> I still do it the same way I worked on code 30 years ago, except now I
> use git instead of cvs. I can't imagine how we could modernize some of
> our development practices without causing unacceptable collateral
> damage, but maybe there's a way, and for sure the way we do things
> around here is pretty far out of the 2023 mainstream. That's something
> we should be grappling with, somehow.

I'm just a newcomer, but I have had some ideas that _don't_ involve
leaving the mailing list paradigm behind, but I will leave those for
another day and another thread :). Perhaps it is worth a talk at
a conference sometime.

--
Tristan Partin
Neon (https://neon.tech)