Обсуждение: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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.

Perhaps the thing to do is ensure that perltidy also uses tabs instead
of spaces.

> src/tools/msvc/Install.pm                       | 1056 ++++++++++---------
> src/tools/msvc/MSBuildProject.pm                |  325 +++---
> src/tools/msvc/Mkvcbuild.pm                     | 1278 ++++++++++++-----------
> src/tools/msvc/Project.pm                       |  607 ++++++------
> src/tools/msvc/Solution.pm                      |  980 +++++++++---------
> src/tools/msvc/VCBuildProject.pm                |  292 +++---
> src/tools/msvc/VSObjectFactory.pm               |  152 ++--
> src/tools/msvc/build.pl                         |   20 +-
> src/tools/msvc/builddoc.pl                      |   32 +-
> src/tools/msvc/config_default.pl                |   38 +-
> src/tools/msvc/gendef.pl                        |   66 +-
> src/tools/msvc/install.pl                       |    4 +-
> src/tools/msvc/pgbison.pl                       |   14 +-
> src/tools/msvc/pgflex.pl                        |   60 +-
> src/tools/msvc/vcregress.pl                     |  400 ++++----

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

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.
> 
> > src/tools/msvc/Install.pm                       | 1056 ++++++++++---------
> > src/tools/msvc/MSBuildProject.pm                |  325 +++---
> > src/tools/msvc/Mkvcbuild.pm                     | 1278 ++++++++++++-----------
> > src/tools/msvc/Project.pm                       |  607 ++++++------
> > src/tools/msvc/Solution.pm                      |  980 +++++++++---------
> > src/tools/msvc/VCBuildProject.pm                |  292 +++---
> > src/tools/msvc/VSObjectFactory.pm               |  152 ++--
> > src/tools/msvc/build.pl                         |   20 +-
> > src/tools/msvc/builddoc.pl                      |   32 +-
> > src/tools/msvc/config_default.pl                |   38 +-
> > src/tools/msvc/gendef.pl                        |   66 +-
> > src/tools/msvc/install.pl                       |    4 +-
> > src/tools/msvc/pgbison.pl                       |   14 +-
> > src/tools/msvc/pgflex.pl                        |   60 +-
> > src/tools/msvc/vcregress.pl                     |  400 ++++----

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

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

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

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

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.

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

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

No idea.  I do not work in those files enough to have an opinion.

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

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 :-)

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

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.

> > > > 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?
>
> No idea.  I do not work in those files enough to have an opinion.

What do others think?  Maybe I'm just being obnoxious here for no useful
gain.

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

On Mon, Jun 11, 2012 at 5:57 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> What do others think?  Maybe I'm just being obnoxious here for no useful
> gain.

I don't think you're being obnoxious; and I also agree with you on the
substance of the issue.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

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.

Why -l=100 instead of -l=78 like our C code?

perltidy changes this code:
for ($long_variable_name_to_initialize = 0;     $long_variable_name_to_initialize < $long_limit_variable_name;
$long_variable_name_to_initialize++){

to this:
for (    $long_variable_name_to_initialize = 0;    $long_variable_name_to_initialize < $long_limit_variable_name;
$long_variable_name_to_initialize++ ){
 

Using -vtc=2 removes the new trailing line break.  Additionally using "-vt=2
-nsak=for" removes the new leading line break, but it also removes the space
between "for" and "(".  Anyone know how to make perltidy format this like we
do in C code?

Why -naws?  I would lean toward "-aws -dws -pt=2" to change code like this:

-my $dbi=DBI->connect('DBI:Pg:dbname='.$opt{d});
+my $dbi = DBI->connect('DBI:Pg:dbname=' . $opt{d});

I'd also consider -kbl=2 to preserve runs of blank lines that the author used
to delineate related groups of functions.

Thanks,
nm

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

On Tue, Jun 12, 2012 at 2:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 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?

I don't think it matters very much - very few commits touch those perl
scripts.  If we have a consensus, I think it's fine to do it now, or
even after we branch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.
> 
> Why -l=100 instead of -l=78 like our C code?
> 
> perltidy changes this code:
> 
>     for ($long_variable_name_to_initialize = 0;
>          $long_variable_name_to_initialize < $long_limit_variable_name;
>          $long_variable_name_to_initialize++)
>     {
> 
> to this:
> 
>     for (
>         $long_variable_name_to_initialize = 0;
>         $long_variable_name_to_initialize < $long_limit_variable_name;
>         $long_variable_name_to_initialize++
>       )
>     {
> 
> Using -vtc=2 removes the new trailing line break.  Additionally using "-vt=2
> -nsak=for" removes the new leading line break, but it also removes the space
> between "for" and "(".  Anyone know how to make perltidy format this like we
> do in C code?
> 
> Why -naws?  I would lean toward "-aws -dws -pt=2" to change code like this:
> 
> -my $dbi=DBI->connect('DBI:Pg:dbname='.$opt{d});
> +my $dbi = DBI->connect('DBI:Pg:dbname=' . $opt{d});
> 
> I'd also consider -kbl=2 to preserve runs of blank lines that the author used
> to delineate related groups of functions.

OK, based on this feedback, I have updated the pgindent README to use
these Perl indent instructions:
       find . -name \*.pl -o -name \*.pm | xargs perltidy \       --backup-and-modify-in-place
--opening-brace-on-new-line\       --vertical-tightness=2 --vertical-tightness-closing=2 \
--nospace-after-keyword=for--nospace-for-semicolon \       --add-whitespace --delete-old-whitespace --paren-tightness=2
\      --keep-old-blank-lines=2 --maximum-line-length=78 \       --entab-leading-whitespace=4
--output-line-ending=unix

Unless I hear otherwise, I will run this new command on the 9.2 and HEAD
Perl files.

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

Bruce Momjian <bruce@momjian.us> writes:
> OK, based on this feedback, I have updated the pgindent README to use
> these Perl indent instructions:

>         find . -name \*.pl -o -name \*.pm | xargs perltidy \
>         --backup-and-modify-in-place --opening-brace-on-new-line \
>         --vertical-tightness=2 --vertical-tightness-closing=2 \
>         --nospace-after-keyword=for --nospace-for-semicolon \
>         --add-whitespace --delete-old-whitespace --paren-tightness=2 \
>         --keep-old-blank-lines=2 --maximum-line-length=78 \
>         --entab-leading-whitespace=4 --output-line-ending=unix

> Unless I hear otherwise, I will run this new command on the 9.2 and HEAD
> Perl files.

No idea what all that stuff does.  Would it be reasonable to post a diff
showing what this would do to the files in question?
        regards, tom lane

On Fri, Jun 15, 2012 at 10:48:27PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > OK, based on this feedback, I have updated the pgindent README to use
> > these Perl indent instructions:
> 
> >         find . -name \*.pl -o -name \*.pm | xargs perltidy \
> >         --backup-and-modify-in-place --opening-brace-on-new-line \
> >         --vertical-tightness=2 --vertical-tightness-closing=2 \
> >         --nospace-after-keyword=for --nospace-for-semicolon \
> >         --add-whitespace --delete-old-whitespace --paren-tightness=2 \
> >         --keep-old-blank-lines=2 --maximum-line-length=78 \
> >         --entab-leading-whitespace=4 --output-line-ending=unix
> 
> > Unless I hear otherwise, I will run this new command on the 9.2 and HEAD
> > Perl files.
> 
> No idea what all that stuff does.  Would it be reasonable to post a diff
> showing what this would do to the files in question?

Sure:
http://momjian.us/expire/perl.diff

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

On Fri, Jun 15, 2012 at 10:45:16PM -0400, Bruce Momjian wrote:
> I have updated the pgindent README to use
> these Perl indent instructions:
> 
>         find . -name \*.pl -o -name \*.pm | xargs perltidy \
>         --backup-and-modify-in-place --opening-brace-on-new-line \
>         --vertical-tightness=2 --vertical-tightness-closing=2 \
>         --nospace-after-keyword=for --nospace-for-semicolon \
>         --add-whitespace --delete-old-whitespace --paren-tightness=2 \
>         --keep-old-blank-lines=2 --maximum-line-length=78 \
>         --entab-leading-whitespace=4 --output-line-ending=unix

I would lean against using --nospace-after-keyword=for.  Not using it means we
get wrong formatting when the for-loop conditions span multiple lines.  Using
it means we get wrong formatting (albeit less severe) on every for-loop.  In
any event, if we do use it for for-loops, we should probably use it for all
control structure keywords.

Otherwise, I like this.

As a last idle idea, how about putting the options in a configuration file and
passing --profile= as the only option?  Besides keeping you from copying a
7-line shell command, this has the benefit of ignoring any ~/.perltidyrc.

Thanks,
nm

On Sat, Jun 16, 2012 at 01:10:31AM -0400, Noah Misch wrote:
> On Fri, Jun 15, 2012 at 10:45:16PM -0400, Bruce Momjian wrote:
> > I have updated the pgindent README to use
> > these Perl indent instructions:
> > 
> >         find . -name \*.pl -o -name \*.pm | xargs perltidy \
> >         --backup-and-modify-in-place --opening-brace-on-new-line \
> >         --vertical-tightness=2 --vertical-tightness-closing=2 \
> >         --nospace-after-keyword=for --nospace-for-semicolon \
> >         --add-whitespace --delete-old-whitespace --paren-tightness=2 \
> >         --keep-old-blank-lines=2 --maximum-line-length=78 \
> >         --entab-leading-whitespace=4 --output-line-ending=unix
> 
> I would lean against using --nospace-after-keyword=for.  Not using it means we
> get wrong formatting when the for-loop conditions span multiple lines.  Using
> it means we get wrong formatting (albeit less severe) on every for-loop.  In
> any event, if we do use it for for-loops, we should probably use it for all
> control structure keywords.

Agreed, good point.

> Otherwise, I like this.
> 
> As a last idle idea, how about putting the options in a configuration file and
> passing --profile= as the only option?  Besides keeping you from copying a
> 7-line shell command, this has the benefit of ignoring any ~/.perltidyrc.

Also agreed, and change made.  Perltidyrc now has:

--add-whitespace--backup-and-modify-in-place--delete-old-whitespace--entab-leading-whitespace=4--keep-old-blank-lines=2--maximum-line-length=78--nospace-for-semicolon--opening-brace-on-new-line--output-line-ending=unix--paren-tightness=2--vertical-tightness=2--vertical-tightness-closing=2

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

On Tue, Jun 12, 2012 at 02:40:09PM -0400, Robert Haas wrote:
> On Tue, Jun 12, 2012 at 2:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > 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?
> 
> I don't think it matters very much - very few commits touch those perl
> scripts.  If we have a consensus, I think it's fine to do it now, or
> even after we branch.

Done.  Run on HEAD and 9.2 --- sorry for the delay.

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