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