Horton

Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2017-05-17T18:41:16Z
Lists: pgsql-hackers 
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Not sure about actually incorporating it into our repo.  Doing so would
>> make it easier for people to use, for sure, and the license seems to be
>> regular 3-clause BSD, so that angle is OK.  But do we want to be carrying
>> around another 150K of source code?

> The alternatives are

> 1. rely on the dead code we've been using so far (the old BSD indent
> patched with our Pg-specific tweaks), or

> 2. rely on someone else's upstream code -- in this case, FreeBSD's as
> patched by Piotr.

> Now that Piotr's is about to find a home, perhaps it's okay for us to
> rely on that one.  I just didn't like the idea of running something from
> Piotr's personal repo.

Well, "pg_bsd_indent is whatever you can find in the FreeBSD repo" is
not a rule that is going to work either.  We need to have a standardized
version that all developers can run and get the same results.  So I
think we'll either have a blessed tarball that we pass around (same
as we do now), or we'll put it into our own tree.  I don't really see
much downside to the latter except bloat.

			regards, tom lane

Commits

  1. Manually un-break a few URLs that pgindent used to insist on splitting.

  2. Remove entab and associated detritus.

  3. Phase 3 of pgindent updates.

  4. Phase 2 of pgindent updates.

  5. Initial pgindent run with pg_bsd_indent version 2.0.

  6. Adjust pgindent script to use pg_bsd_indent 2.0.

  7. Final pgindent run with old pg_bsd_indent (version 1.3).

  8. Re-run pgindent.

  9. Preventive maintenance in advance of pgindent run.