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 20090812133830.GD5721@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)  (Robert Haas <robertmhaas@gmail.com>)
Responses 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: 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>)
List pgsql-hackers
Robert Haas escribió:
> On Wed, Aug 12, 2009 at 12:27 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

> > 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:

> That is truly bizarre.  +1 from me for doing something that a
> competent C programmer can figure out without a calculator.  I don't
> care what the rule is particularly, as long as it's obvious how to
> follow it.  (In my own code I indent all of my continuation lines by
> one additional 4-space tab-stop.  I realize this would be a horrible
> idea for PG since we don't want to change anything that's going to
> reindent the entire code base, and you might all hate it for other
> reasons anyway, but the point is that any idiot can look at it and
> figure out how it's supposed to be indented, because the rule is
> simple.)

Well, the rule here is simple too (set cinoptions=(0 if you're
Vim-enabled).  It's only function prototypes that are a bit weird, and
once you understand how it works it's trivial to reproduce.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: WIP: getting rid of the pg_database flat file
Next
From: Tom Lane
Date:
Subject: Re: WIP: getting rid of the pg_database flat file