Re: Preliminary results for proposed new pgindent implementation

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
Subject: Re: Preliminary results for proposed new pgindent implementation
Date: 2017-05-19 16:30:08
Message-ID: 20170519163008.6algqcf66ldu2bxa@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-05-19 12:21:52 -0400, Robert Haas wrote:
> On Fri, May 19, 2017 at 11:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I certainly would rather that our version matched something that's under
> > active maintenance someplace. But it seems like there are two good
> > arguments for having a copy in our tree:
> >
> > * easy accessibility for PG developers
> >
> > * at any given time we need to be using a specific "blessed" version,
> > so that all developers can get equivalent results. There's pretty much
> > no chance of that happening if we depend on distro-provided packages,
> > even if those share a common upstream.
>
> Yeah, but those advantages could also be gained by putting the
> pgindent tree on git.postgresql.org in a separate repository. Having
> it in the same repository as the actual PostgreSQL code is not
> required nor, in my opinion, particularly desirable.

I'm of the contrary opinion. A lot of the regular churn due to pgindent
right now is because it's inconvenient to run. Having to clone a
separate repository, compile that project, put it into PATH (fun if
there's multiple versions), run pgindent, discover typedefs.list is out
of date, update, run, ... is pretty much a guarantee that'll continue.
If we had a make indent that computed local typedefs list, *added* new
but not removed old ones, we could get much closer to just always being
properly indented.

The cost of putting it somewhere blow src/tools/pgindent seems fairly
minor.

- Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-05-19 16:31:14 Re: Preliminary results for proposed new pgindent implementation
Previous Message Robert Haas 2017-05-19 16:21:52 Re: Preliminary results for proposed new pgindent implementation