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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: 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 20:31:43
Message-ID: 603c8f070908101331t19584807y7205fb8bff4da87f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Mon, Aug 10, 2009 at 4:22 PM, Alvaro
Herrera<alvherre(at)commandprompt(dot)com> wrote:
> Robert Haas escribi├│:
>> On Mon, Aug 10, 2009 at 4:16 PM, Alvaro Herrera<alvherre(at)postgresql(dot)org> wrote:
>> > Log Message:
>> > -----------
>> > Refactor NUM_cache_remove calls in error report path to a PG_TRY block.
>> >
>> > The code in the new block was not reindented; it will be fixed by pgindent
>> > eventually.
>>
>> ...breaking every patch that someone has in progress against that code?
>
> I guess I neglected to add "a year from now or so".  I'm not in a hurry
> to run pgindent.

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.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-08-10 20:31:55
Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Previous:From: Robert HaasDate: 2009-08-10 20:28:01
Subject: Re: machine-readable explain output v4

pgsql-committers by date

Next:From: Tom LaneDate: 2009-08-10 20:31:55
Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Previous:From: Alvaro HerreraDate: 2009-08-10 20:22:47
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