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

On Mon, Aug 10, 2009 at 4:31 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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