Re: Preliminary results for proposed new pgindent implementation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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:49:10
Message-ID: 2788.1495212550@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-05-19 12:21:52 -0400, Robert Haas wrote:
>> 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.

I hadn't really thought of automating it to that extent, but yeah,
that seems like an interesting prospect.

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

I think the main cost would be bloating distribution tarballs. Although
we're talking about adding ~50K to tarballs that are already pushing 20MB,
so realistically who's going to notice? If you want to cut the tarball
size, let's reopen the discussion about keeping release notes since the
dawn of time.

Also, having the support in distributed tarballs is not all bad, because
it would allow someone working from a tarball rather than a git pull
to have pgindent support. Dunno if there are any such someones anymore,
but maybe they're out there.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Cyril Auburtin 2017-05-19 16:50:55 Allowing dash character in LTREE
Previous Message Tom Lane 2017-05-19 16:38:13 Re: Preliminary results for proposed new pgindent implementation