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

From Bruce Momjian
Subject Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Date
Msg-id 20120612180200.GB22649@momjian.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3  (Noah Misch <noah@leadboat.com>)
Responses Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
List pgsql-hackers
On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote:
> On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
> > What about something like this in the root of the tree:
> > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix
> > 
> > There are files all over the place.  The file that would most be
> > affected with one run of this is the ECPG grammar generator.
> > 
> > I checked the "-et=4" business (which is basically entab).  We're pretty
> > inconsistent about tabs in perl code it seems; some files use tabs
> > others use spaces.  Honestly I would just settle on what we use on C
> > files, even if the Perl devs don't recommend it "because of
> > maintainability and portability".  I mean if it works well for us for C
> > code, why would it be a problem in Perl code?  However, I don't write
> > much of that Perl code myself.
> 
> +1 for formatting all our Perl scripts and for including -et=4.  Since that
> will rewrite currently-tidy files anyway, this is a good time to audit our
> perltidy settings.

OK, another open question is whether we should do any of these changes
now for 9.2/9.3 or wait for 9.3/9.4?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Next
From: Robert Haas
Date:
Subject: Re: 9.3: load path to mitigate load penalty for checksums