Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Дата
Msg-id 603c8f070908111042t71e51181j788095dba7fea205@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Tue, Aug 11, 2009 at 12:52 PM, Andrew Dunstan<andrew@dunslane.net> wrote:
> Robert Haas wrote:
>>
>> I'm not sure there's a
>> good solution to this problem short of making pgindent easy enough
>> that we can make it a requirement for patch submission, and I'm not
>> sure that's practical.
>>
>> But in any case, I think running pgindent immediately after the last
>> CommitFest rather than after a longish delay would be a good idea.
>
> Frankly, fixing up patch bitrot caused by pgindent is not terribly difficult
> in my experience - bitrot caused by code drift is a much harder problem (and
> yes, git fans, I know git can help with that).

Where it really bit me as when it reindented the DATA() statements
that were touched by ALTER TABLE ... SET STATISTICS DISTINCT.  It's
not so hard to compare code, but comparing DATA() lines is the pits.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: "Hot standby"?
Следующее
От: Ron Mayer
Дата:
Сообщение: Re: "Hot standby"?