Jelte Fennema-Nio <[email protected]> writes:
> On Thu, 24 Sept 2026 at 16:29, Tom Lane <[email protected]> wrote:
>> I object to this patch. src/tools/pgindent/README documents that
>> the presence of those files is useful for detecting where pgindent
>> failed. Without them there's not an easy signal.
> Hard disagree. I don't think BAK files serve that purpose well, and
> they should be removed always imo (or possibly not even created in the
> first place). There are two much better signals for detecting whether
> and how pgindent fails:
> 1. stderr of pgindent
> 2. exit code of pgindent
You fail to get my point. When doing a full-tree run, it's not enough
to get a binary pass/fail signal: it's necessary to know which files
pgindent failed on, so you can go look at them and fix them. IMO
the .BAK files are actually quite well adapted for this, because you
can go fix the first failing file, remove its .BAK file, and then the
other .BAK files are still there to remind you what else to look at.
pgindent's exit code is utterly inadequate for that. And even if it
prints just what you need to know on stderr, that's transient data
that has probably scrolled off your terminal window by the time you
finished with the first problem.
Is that perfect? Hardly; I can definitely think of better UX
experiences. But it beats having zero bread-crumbs, which is where
Peter's patch would leave us. If you want to get rid of the .BAK
files, provide a superior substitute *first*.
regards, tom lane
