Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date: 2009-08-12 01:05:29
Message-ID: 2091.1250039129@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> What would happen if we ran pgindent immediately after every commit?
> So nobody would ever see a checkout that wasn't pgindent-clean?

> The only losers I see would be people working on multi-part patches.

... which we're trying to encourage ...

Actually, the case that started this thread is relevant: a forced
reindent would be *more* likely to have broken other patches than
not doing one.  I don't really like removing human judgment from
the process.

It definitely would help if large sections of new code were properly
indented before they got committed (assuming there are not followup
patches already prepared).  In the case of modifications to existing
code, the question is not nearly so black-and-white.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-08-12 01:10:06
Subject: Re: WIP: getting rid of the pg_database flat file
Previous:From: Robert HaasDate: 2009-08-12 01:04:48
Subject: Re: Alpha 1 release notes

pgsql-committers by date

Next:From: Robert HaasDate: 2009-08-12 01:29:26
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Previous:From: Greg StarkDate: 2009-08-12 00:10:01
Subject: Re: pgindent timing (was Re: [COMMITTERS] 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