Re: WIP pgindent replacement - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: WIP pgindent replacement
Date
Msg-id 201106220218.p5M2InB08144@momjian.us
Whole thread Raw
In response to WIP pgindent replacement  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan wrote:
> 
> Attached is a WIP possible replacement for pgindent. Instead of a shell 
> script invoking a mishmash of awk and sed, some of which is pretty 
> impenetrable, it uses a single engine (perl) to do all the pre and post 
> indent processing. Of course, if your regex-fu and perl-fu is not up the 
> scratch this too might be impenetrable, but all but a couple of the 
> recipes are reduced to single lines, and I'd argue that they are all at 
> least as comprehensible as what they replace.

I am excited Andrew has done this.  It has been on my TODO list for a
while --- I was hoping someday we could switch to GNU indent but gave up
after the GNU indent report from Greg Stark that exactly matched my
experience years ago:
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01436.php

Basically, GNU indent has new bugs, but bugs that are harder to work
around than the BSD indent bugs.

Once I heard that I realized we were going to be using BSD indent for
many more years to come and rewriting the shell script in Perl was the
next logical step, which Andrew has done.

This will also allow us to use pgindent on Windows that has Perl
installed --- we should create a DOS binary of bsd indent so Windows
users scan run it.

I would also like to add a command-line way to detect our patched
version of BSD indent so we know we are using the right binary.  I will
do that once the Perl version is committed to git.

Thanks Andrew.

--  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: Robert Haas
Date:
Subject: Re: Auto Start second postgres 8.3.15-1 instance MAC OS X
Next
From: Robert Haas
Date:
Subject: Re: Identifying no-op length coercions