Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Date: 2009-08-10 23:08:04
Message-ID: 26391.1249945684@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-08-10 23:22:44
Subject: Re: hot standby - merged up to CVS HEAD
Previous:From: Tom LaneDate: 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 HaasDate: 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 LaneDate: 2009-08-10 22:52:04
Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group