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 20120612150406.GA22649@momjian.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
> 
> Excerpts from Bruce Momjian's message of lun jun 11 15:44:16 -0400 2012:
> > 
> > On Mon, Jun 11, 2012 at 12:20:13PM -0400, Alvaro Herrera wrote:
> > > > > 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
> > 
> > Not sure.  I just followed the README instructions.  I should just
> > probably mention the Perl files were not processed by pgindent on the
> > commit.
> 
> Well, you wrote the instructions yourself :-)

Well, initially, yes, but others have improved them over time.

> > > 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)
> > 
> > I was not aware of them.  If you want them run, would you update the
> > pgindent README to mention them please?
> 
> 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.

Sounds like a good idea to me.

> 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.

Yes, I would love to hear a Perl person chime in here to tell us it is
OK, as you stated.

I suppose if we don't get any feedback in a few days, let's just go
ahead and make the changes you suggested.

--  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: Magnus Hagander
Date:
Subject: Re: 9.2 final
Next
From: Noah Misch
Date:
Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)