Re: Why does pgindent's README say to download typedefs.list from the buildfarm?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Why does pgindent's README say to download typedefs.list from the buildfarm?
Date: 2024-04-23 14:11:45
Message-ID: 3329415.1713881505@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2024-Apr-22, Tom Lane wrote:
>> The main reason there's a delta is that people don't manage to
>> maintain the in-tree copy perfectly (at least, they certainly
>> haven't done so for this past year). So we need to do that
>> to clean up every now and then.

> Out of curiosity, I downloaded the buildfarm-generated file and
> re-indented the whole tree. It turns out that most commits seem to have
> maintained the in-tree typedefs list correctly when adding entries (even
> if out of alphabetical order), but a few haven't; and some people have
> added entries that the buildfarm script does not detect.

Yeah. I believe that happens when there is no C variable or field
anywhere that has that specific struct type. In your example,
NotificationHash appears to only be referenced in a sizeof()
call, which suggests that maybe the coding is a bit squirrely
and could be done another way.

Having said that, there already are manually-curated lists of
inclusions and exclusions hard-wired into pgindent (see around
line 70). I wouldn't have any great objection to adding more
entries there. Or if somebody wanted to do the work, they
could be pulled out into separate files.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guo, Adam 2024-04-23 14:45:20 pg_trgm comparison bug on cross-architecture replication due to different char implementation
Previous Message David Rowley 2024-04-23 13:45:25 Re: Minor document typo