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

From Tom Lane
Subject Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date
Msg-id 2750.1250042938@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> What is a bit frustrating to me is that a number of Tom's changes to
> the first two patches were trivial whitespace changes that required me
> to rebase for no obvious reason.   Either those changes were made
> accidentally as Tom was fooling around with what I had done, or they
> were made because Tom had some reason to believe that they would play
> more nicely with pgindent, though what those reasons may have been is
> entirely opaque to me.

I tend to do some manual adjustment to pgindent rules in places where
I feel it makes the code more readable.  (Bear in mind that I've been
looking at the Postgres code base for long enough that large variations
from pgindent style are automatically less readable for me...)  If I'd
realized you had followon patches touching the same spots I would've
possibly refrained from that.  Although the nearby suggestions that we
should run pgindent more often would render it moot ;-).

If that's not it, you'd need to mention details.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: "Hot standby"?
Next
From: Robert Haas
Date:
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)