Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Date
Msg-id 1339431158-sup-9441@alvh.no-ip.org
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
List pgsql-hackers
Excerpts from Bruce Momjian's message of dom jun 10 22:37:14 -0400 2012:
>
> On Sun, Jun 10, 2012 at 08:55:13PM -0400, Alvaro Herrera wrote:
> >
> > Excerpts from Bruce Momjian's message of dom jun 10 15:20:34 -0400 2012:
> > > Run pgindent on 9.2 source tree in preparation for first 9.3
> > > commit-fest.
> >
> > Hm, does this touch stuff that would also be modified by perltidy?  I
> > wonder if we should refrain from doing entab/detab on perl files and
> > instead have perltidy touch such code.

> The Perl files were modified by perltidy and not by pgindent, as
> documented in the pgindent README:
>
>     9) Indent the Perl MSVC code:
>
>             cd src/tools/msvc
>             perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm

Oh, I see.  That's great then.  Should those change be committed
separately, just to avoid confusion?  BTW those aren't the only Perl
files in the source tree -- we also have the genbki stuff, for example.
(There is already some inconsistency in tabs/spaces in genbki.pl
already)

> > Perhaps the thing to do is ensure that perltidy also uses tabs instead
> > of spaces.
>
> If you would like 'entab' run on the Perl files, let me know.

Whatever perltidy emits is fine with me, but should we consider passing
-et=4 to perltidy?

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [ADMIN] pg_basebackup blocking all queries with horrible performance
Next
From: Joshua Berkus
Date:
Subject: Re: 9.2 final