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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 21:39:30
Message-ID: 603c8f070908101439x2adece70t2efad37f8100be32@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-08-10 22:03:11
Subject: Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Previous:From: Stephen FrostDate: 2009-08-10 21:28:42
Subject: Re: GRANT ON ALL IN schema

pgsql-committers by date

Next:From: Alvaro HerreraDate: 2009-08-10 22:03:11
Subject: Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Previous: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

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