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

From Alvaro Herrera
Subject Re: run pgindent on a regular basis / scripted manner
Date
Msg-id 20230123173820.5taw5j5axceifsdz@alvherre.pgsql
Whole thread Raw
In response to run pgindent on a regular basis / scripted manner  (Andres Freund <andres@anarazel.de>)
Responses Re: run pgindent on a regular basis / scripted manner
List pgsql-hackers
On 2023-Jan-23, Tom Lane wrote:

> 1. [...] 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.

+1

> 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.

+1

> 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.

Hmm, initially it must just be easier to have an exception so that
pg_bsd_indent itself isn't indented.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
#error "Operator lives in the wrong universe"
  ("Use of cookies in real-time system development", M. Gleixner, M. Mc Guire)



pgsql-hackers by date:

Previous
From: gkokolatos@pm.me
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Robert Haas
Date:
Subject: Re: Non-superuser subscription owners