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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers