Re: run pgindent on a regular basis / scripted manner - Mailing list pgsql-hackers

From Tom Lane
Subject Re: run pgindent on a regular basis / scripted manner
Date
Msg-id 2626665.1697506332@sss.pgh.pa.us
Whole thread Raw
In response to Re: run pgindent on a regular basis / scripted manner  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: run pgindent on a regular basis / scripted manner
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> My main objection to the new policy is that it's not quite clear what
> process I should go through in order to be 100% confident that koel
> won't start whining (short of waiting around for koel to whine). I
> know how to run pgindent, of course, and haven't had any problems so
> far...but it still seems quite haphazard. If we're going to make this
> a hard rule, enforced on every commit, it should be dead easy to
> comply with the rule.

But it's *not* a hard rule --- we explicitly rejected mechanisms
that would make it so (such as a precommit hook).  I view "koel
is unhappy" as something that you ought to clean up, but if you
don't get to it for a day or three there's not much harm done.

In theory koel might complain even if you'd locally gotten
clean results from pgindent (as a consequence of skew in the
typedef lists being used, for example).  We've not seen cases
of that so far though.  Right now I think we just need to raise
committers' awareness of this enough that they routinely run
pgindent on the files they're touching.  In the problem cases
so far, they very clearly didn't.  I don't see much point in
worrying about second-order problems until that first-order
problem is tamped down.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Quan Zongliang
Date:
Subject: Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
Next
From: Krishnakumar R
Date:
Subject: Re: Move bki file pre-processing from initdb to bootstrap