Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY - Mailing list pgsql-committers

From Robert Haas
Subject Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Date
Msg-id 603c8f070908101439x2adece70t2efad37f8100be32@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
List pgsql-committers
On Mon, Aug 10, 2009 at 4:31 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Robert Haas escribió:
>>>> 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.
>
> 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 and they will break again when the pgindent run is done.  If the
indentation is fixed at commit-time (or before someone goes to the
trouble of fixing them), then they get broken only once.  I guess it's
not the end of the world, but it sure seems like the less work
pgindent does when it is run, the better.

...Robert

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Next
From: alvherre@postgresql.org (Alvaro Herrera)
Date:
Subject: pgsql: Fix number of columns declared for pg_user_mappings description