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

From Tom Lane
Subject Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date
Msg-id 4554.1250053254@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> The reason this is like this is that the indent binary modifies the
> prototype exactly like the function definition, and then the awk program
> that's used in the pipeline "pulls up" the second line:

> #  Move prototype names to the same line as return type.  Useful for ctags. 
> #  Indent should do this, but it does not.  It formats prototypes just
> #  like real functions.

> In this day and age there's probably no reason to do this.

Um, sorry, no reason to do which?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: TODO: fix priority of ordering of read and write light-weight locks
Next
From: Peter Eisentraut
Date:
Subject: Re: Alpha 1 release notes