Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) - Mailing list pgsql-hackers

On Tue, Aug 11, 2009 at 12:52 PM, Andrew Dunstan<andrew@dunslane.net> wrote:
> Robert Haas wrote:
>>
>> I'm not sure there's a
>> good solution to this problem short of making pgindent easy enough
>> that we can make it a requirement for patch submission, and I'm not
>> sure that's practical.
>>
>> But in any case, I think running pgindent immediately after the last
>> CommitFest rather than after a longish delay would be a good idea.
>
> Frankly, fixing up patch bitrot caused by pgindent is not terribly difficult
> in my experience - bitrot caused by code drift is a much harder problem (and
> yes, git fans, I know git can help with that).

Where it really bit me as when it reindented the DATA() statements
that were touched by ALTER TABLE ... SET STATISTICS DISTINCT.  It's
not so hard to compare code, but comparing DATA() lines is the pits.

...Robert