Re: run pgindent on a regular basis / scripted manner

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Jelte Fennema <postgres(at)jeltef(dot)nl>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie>, Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Jesse Zhang <sbjesse(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: run pgindent on a regular basis / scripted manner
Date: 2023-02-02 14:06:36
Message-ID: 1215f2de-3c49-eb3a-e62b-da1c05cb51db@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-02-02 Th 01:40, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
>> Regarding the concern about a pre-receive hook blocking an emergency push, the
>> hook could approve every push where a string like "pgindent: no" appears in a
>> commit message within the push. You'd still want to make the tree clean
>> sometime the same week or so. It's cheap to provide a break-glass like that.
> I think the real question here is whether we can get all (or at least
> a solid majority of) committers to accept such draconian constraints.
> I'd buy into it, and evidently so would you, but I can't help noting
> that less than a quarter of active committers have bothered to
> comment on this thread. I suspect the other three-quarters would
> be quite annoyed if we tried to institute such requirements. That's
> not manpower we can afford to drive away.

I'd be very surprised if this caused any active committer to walk away
from the project. Many will probably appreciate the nudge. But maybe I'm
overoptimistic.

>
> Maybe this should get taken up at the this-time-for-sure developer
> meeting at PGCon?
>
>

Sure. There's probably some work that could still be done in this area
too, such as making pgperltidy work similarly to how we've now make
pgindent work.

There's also a question of timing. Possibly the best time would be when
we next fork the tree.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-02-02 14:07:27 Re: pg_stat_statements and "IN" conditions
Previous Message jacktby@gmail.com 2023-02-02 14:00:56 How to write a new tuple into page?