Skip site navigation (1) Skip section navigation (2)

Re: branching for 9.2devel

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: branching for 9.2devel
Date: 2011-04-26 01:02:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On 04/25/2011 08:54 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net>  writes:
>> On 04/25/2011 07:48 PM, Tom Lane wrote:
>>> Well, -Ttypedef is wrong on its face.  Right would be a switch
>>> specifying the name of the file to read the typedef list from.
>>> Then you don't need massive script-level infrastructure to try
>>> to spoonfeed that data to the program doing the work.
>> Ok, but that would account for about 5 lines of the current 400 or so in
>> pgindent, and we'd have to extend our patch of BSD indent to do it.
> Huh?  I thought the context here was reimplementing it from scratch in
> perl.


>> That's not to say that we shouldn't, but we should be aware of how much
>> it will buy us on its own.
> The point isn't so much to remove a few lines of shell code (though I
> think that's a bigger deal than you say, if we want this to be usable on
> Windows).  It's to not run into shell line length limits, which I
> believe we are dangerously close to already on many platforms.

The current script calls our (patched) BSD indent. Any rewrite would 
have to also. It (the BSD indent) doesn't have any facility to pass a 
typedef file parameter. If you want that we have to patch the C code. No 
amount of rewriting in Perl or anything else would overcome that. My 
suggestion was to work around it as part of a script rewrite, but you 
didn't seem to like that idea.



In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-04-26 01:07:03
Subject: Re: branching for 9.2devel
Previous:From: Robert HaasDate: 2011-04-26 00:55:57
Subject: Re: pg_upgrade cleanup

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group