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 Alvaro Herrera
Subject Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date
Msg-id 20090812045440.GS16362@alvh.no-ip.org
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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
List pgsql-hackers
Tom Lane escribió:

> Ah.  That's a bit idiosyncratic to pgindent.  What it does for a
> function definition makes sense, I think: it lines up all the
> parameters to start in the same column:
> 
> static int
> myfunction(int foo,
>            int bar)
> 
> What is not obvious is that the same amount of hanging indent is
> used for the function's *prototype*, even though the first line
> is not the same:
> 
> static int myfunction(int foo,
>            int bar);
> 
> ie, the indent is length of function name plus 1.  I find this a bit
> stupid myself 

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.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Hot standby and synchronous replication status
Next
From: Tom Lane
Date:
Subject: Re: TODO: fix priority of ordering of read and write light-weight locks