Re: 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-committers(at)postgresql(dot)org
Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Date: 2009-08-10 22:52:04
Message-ID: 26144.1249944724@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 10, 2009 at 4:31 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah --- if there are any active patches against that code (a fact not
>> in evidence) then reindenting now would break them now. Leaving it till
>> the next pgindent run seems fine to me.

> But if there are patches against that code, then they've been broken
> now

Uh, no --- the point here is that something like two hundred lines of
code were *not* changed by reindenting. Diffs in that area would likely
still apply.

> and they will break again when the pgindent run is done.

Only if they aren't applied by then. One reason that we normally only
run pgindent at the end of the devel cycle is that that's when
(presumably) the smallest amount of patches remain outstanding.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2009-08-10 23:08:04 Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Previous Message Alvaro Herrera 2009-08-10 22:42:41 pgsql: Fix URL to "The Hitch-Hiker's Guide to Evolutionary Computation".

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-08-10 23:08:04 Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Previous Message David Fetter 2009-08-10 22:49:30 Re: hot standby - merged up to CVS HEAD