Re: Run pgindent now?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>
Cc: 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-26 19:53:54
Message-ID: 5564CF52.2060402@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 05/25/2015 05:34 PM, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
>>> Something is wrong. See aclchk.c changes.
>> Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0
>> and 9.1, and the use of that as a typedef in 9.4 is certainly odd:
>> - aclitem.ai_grantor = grantorId;
>> + aclitem. ai_grantor = grantorId;
> Yeah. I think we might've gotten rid of that typedef partially in order
> to fix this.
>
> A different strategy we could consider is "use HEAD's typedef list
> even in the back branches". This would in some situations lead to
> inferior-looking results in the back branches, but that's probably better
> than inferior results in HEAD. (In any case, we want the same typedef
> list across all branches. Then anyplace where the results diverge, there
> must have been non-pgindent code changes, so that back-patching would
> require manual fixups anyway.)
>
> A longer-term fix would be to make pgindent less stupid about this sort
> of usage, but nobody's yet volunteered to dig into the guts of that code.
>
>

It looks to me like this says we should use the typedefs for each branch
in any pgindent run for that branch, with the list being fetched just
before each run, so it reflects any backpatches, bug fixes etc.

The buildfarm collects these lists for all live branches now (or at
least my animals do) and keeps them up to date.

Anything else is likely to lead to false positives with results like
that above.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-05-26 20:44:03 Re: fsync-pgdata-on-recovery tries to write to more files than previously
Previous Message Jeff Janes 2015-05-26 19:37:08 Re: optimizing vacuum truncation scans