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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Следующее
От: alvherre@postgresql.org (Alvaro Herrera)
Дата:
Сообщение: pgsql: Fix number of columns declared for pg_user_mappings description