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: 4DB61998.4080506@dunslane.net (view raw or flat)
Thread:
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.


yes.

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

cheers

andrew

In response to

Responses

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-2014 The PostgreSQL Global Development Group