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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, 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 04:54:40
Message-ID: 20090812045440.GS16362@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2009-08-12 05:00:54 Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Previous Message Tom Lane 2009-08-12 04:27:16 Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-08-12 04:58:29 Re: TODO: fix priority of ordering of read and write light-weight locks
Previous Message Markus Wanner 2009-08-12 04:48:19 Re: "Hot standby"?