Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Me neither, but every place that we know pgindent will touch is like a
> little land-mine waiting to go off under somebody's patch.  It seems
> like we ought to try to keep the tree as pgindent-clean as possible
> when we make changes, so that there are as few of those land-mines out
> there as possible.

You're ignoring the difference between two significantly different
scenarios.  When code that was never in the tree gets added, yeah
it's probably good if it's reindented immediately.  But in this
case we are talking about code that is already in the tree, and
has been for awhile, needing to be reindented because of some
changes that aren't textually all that close by.  We will break
any outstanding patches against that code when we reindent it, but
it is not at all clear that it's better to do that now than
later.  There are likely to be fewer patches outstanding at the
end of the devel cycle than there are now.

			regards, tom lane

In response to

• Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY at 2009-08-10 20:31:43 from Robert Haas

pgsql-hackers by date

Next:	From: Bruce Momjian	Date: 2009-08-10 23:22:44
	Subject: Re: hot standby - merged up to CVS HEAD
Previous:	From: Tom Lane	Date: 2009-08-10 22:52:04
	Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY

pgsql-committers by date

Next:	From: Robert Haas	Date: 2009-08-11 03:40:04
	Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Previous:	From: Tom Lane	Date: 2009-08-10 22:52:04
	Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY