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: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Date
Msg-id 26391.1249945684@sss.pgh.pa.us
Whole thread Raw
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: hot standby - merged up to CVS HEAD
Next
From: Bruce Momjian
Date:
Subject: Re: hot standby - merged up to CVS HEAD