Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
От | Robert Haas |
---|---|
Тема | Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY |
Дата | |
Msg-id | 603c8f070908101439x2adece70t2efad37f8100be32@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
|
Список | 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 по дате отправления: