Re: pgindent to ignore build directories

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgindent to ignore build directories
Date: 2026-09-28 03:25:27
Message-ID: 428615.1790565927@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> writes:
> On Thu, 24 Sept 2026 at 16:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-09-28 03:32:03 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Michael Paquier 2026-09-28 03:13:02 Re: ZSTD TOAST compression, and an extensible compression method encoding