From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Run pgindent now? |
Date: | 2015-05-27 18:55:09 |
Message-ID: | 5722.1432752909@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> But really, the typedef list is the minor part what annoys me about
> pgindent. That it completely butchers so many constructs (e.g. function
> pointer typedefs, inline asm as extreme examples) is much worse.
These are all things we might try to fix (where "fix" could include
"replace it with another tool") if the back-patching pain created by even
minor changes of the formatting rules weren't so great. But at this point
I despair of getting to consensus on a way to relieve that pain. Robert's
position seems to be that there is no such pain, which I beg to differ
with, but given that position he's naturally unwilling to accept any
invasive measures to alleviate it.
> It's
> also neigh on impossible to predict/keep the indentation pgindent will
> use in many cases. Having to try to write code in a way that doesn't
> break the re-indentation tool, even if it'd otherwise be fine, is just
> absurd.
Not clear to me why you need to "predict" anything ... just run the tool
and see what it does. Admittedly, we should do more to make it easy for
occasional contributors to use the tool, but I do not think it's
unreasonable to expect committers to have it set up and use it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ted Toth | 2015-05-27 19:25:46 | Re: rhel6 rpm file locations |
Previous Message | Andrew Dunstan | 2015-05-27 18:51:03 | Re: [PATCH] Generalized JSON output functions |