Re: run pgindent on a regular basis / scripted manner
От | Nikita Malakhov |
---|---|
Тема | Re: run pgindent on a regular basis / scripted manner |
Дата | |
Msg-id | CAN-LCVNctZtm=GGa7WSxyH85GQDof-h0ok4v1VcS+8j1LivApg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: run pgindent on a regular basis / scripted manner (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: run pgindent on a regular basis / scripted manner
|
Список | pgsql-hackers |
Hi!
I've ran pdindent on the whole Postgres and it'd changed
an awful lot of source files. Won't it create a lot of merge conflicts?
On Mon, Jan 23, 2023 at 8:48 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
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 по дате отправления: