Horton
Menu

Re: run pgindent on a regular basis / scripted manner

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Jelte Fennema <postgres@jeltef.nl>, Peter Geoghegan <pg@bowt.ie>, Bruce Momjian <bruce@momjian.us>, Magnus Hagander <magnus@hagander.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Noah Misch <noah@leadboat.com>, Jesse Zhang <sbjesse@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-01-23T15:09:06Z
Lists: pgsql-hackers 
I wrote:
> Cool.  I'll take a look at doing this later (probably after the current
> CF) unless somebody beats me to it.

Thinking about that (importing pg_bsd_indent into our main source
tree) a bit harder:

1. I'd originally thought vaguely that we could teach pgindent
how to build pg_bsd_indent automatically.  But with a little
more consideration, I doubt that would work transparently.
It's common (at least for me) to run pgindent in a distclean'd
tree, where configure results wouldn't be available.  It's even
worse if you habitually use VPATH builds, so that those files
*never* exist in your source tree.  So now I think that we should
stick to the convention that it's on the user to install
pg_bsd_indent somewhere in their PATH; all we'll be doing with
this change is eliminating the step of fetching pg_bsd_indent's
source files from somewhere else.

2. Given #1, it'll be prudent to continue having pgindent
double-check that pg_bsd_indent reports a specific version
number.  We could imagine starting to use the main Postgres
version number for that, but I'm inclined to continue with
its existing numbering series.  One argument for that is
that we generally change pg_bsd_indent less often than annually,
so having it track the main version would end up forcing
make-work builds of your installed pg_bsd_indent at least
once a year.  Also, when we do change pg_bsd_indent, it's
typically right before a mass reindentation commit, and those
do not happen at the same time as forking a new PG version.

3. If we do nothing special, the first mass reindentation is
going to reformat the pg_bsd_indent sources per PG style,
which is ... er ... not the way they look now.  Do we want
to accept that outcome, or take steps to prevent pgindent
from processing pg_bsd_indent?  I have a feeling that manual
cleanup would be necessary if we let such reindentation
happen, but I haven't experimented.

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix comment from commit 22655aa231.

  2. Add a few recent commits to .git-blame-ignore-revs.

  3. Pre-beta2 mechanical code beautification.

  4. Pre-beta mechanical code beautification.

  5. Make agreed-on updates in perltidy options.

  6. Remove obsolete pgindent options --code-base and --build

  7. Integrate pg_bsd_indent into our build/test infrastructure.

  8. Sync pg_bsd_indent's copyright notices with Postgres practice.

  9. Import pg_bsd_indent sources.

  10. pgindent: filter files for the --commit option

  11. pgindent: more ways to find files to indent

  12. Fix pgindent --show-diff option.

  13. Add non-destructive modes to pgindent

  14. Initial pgindent run with pg_bsd_indent version 2.0.