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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Дата
Msg-id 2750.1250042938@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> What is a bit frustrating to me is that a number of Tom's changes to
> the first two patches were trivial whitespace changes that required me
> to rebase for no obvious reason.   Either those changes were made
> accidentally as Tom was fooling around with what I had done, or they
> were made because Tom had some reason to believe that they would play
> more nicely with pgindent, though what those reasons may have been is
> entirely opaque to me.

I tend to do some manual adjustment to pgindent rules in places where
I feel it makes the code more readable.  (Bear in mind that I've been
looking at the Postgres code base for long enough that large variations
from pgindent style are automatically less readable for me...)  If I'd
realized you had followon patches touching the same spots I would've
possibly refrained from that.  Although the nearby suggestions that we
should run pgindent more often would render it moot ;-).

If that's not it, you'd need to mention details.
        regards, tom lane


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: "Hot standby"?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)