Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY

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