Re: pgindent versus struct members and typedefs

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Rahila Syed <rahilasyed90(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgindent versus struct members and typedefs
Date: 2025-12-02 22:46:33
Message-ID: 347EA055-D626-414C-B10D-7E70041B9B55@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Dec 3, 2025, at 06:00, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Mon, Dec 01, 2025 at 05:04:23PM -0600, Nathan Bossart wrote:
>> On Tue, Dec 02, 2025 at 05:35:34AM +0800, Chao Li wrote:
>>> ```
>>> + else if (entry->type == DSMR_ENTRY_TYPE_DSH &&
>>> + entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
>>> ```
>>>
>>> Missing a white space after !=.
>>
>> I agree, but for some reason, pgindent insists on removing that space. I'm
>> leaving that for another thread.
>
> So, this seems to have something to do with the struct member having the
> same name as a typedef. If I rename the member, pgindent adds the space as
> expected. Interestingly, changing the != to a == also fixes the spacing.
> There are a couple of other examples in the code:
>
> src/backend/storage/ipc/dsm_registry.c: entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
> src/backend/replication/logical/logicalfuncs.c: ctx->options.output_type !=OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
> src/bin/pg_basebackup/pg_basebackup.c: if (state.manifest_file !=NULL)
> src/bin/pg_basebackup/pg_basebackup.c: state->manifest_file !=NULL)
> src/bin/pg_basebackup/pg_basebackup.c: else if (state->manifest_file !=NULL)
>
> I used the following command to find these:
>
> grep -E "!=[A-Za-z]" ./* -rI
>
> AFAICT this is a special case of the note added to pgindent's README by
> commit c4133ec:
>
> pgindent will mangle both declaration and definition of a C function whose
> name matches a typedef. Currently the best workaround is to choose
> non-conflicting names.
>
> I tried to fix pgindent for a few, but the code is basically impenetrable.
> I didn't find any fixes upstream [0], either. As noted above, we could
> also fix it by avoiding the naming conflicts. However, I can't imagine
> that's worth the churn, and I've already spent way too much time on this,
> so IMHO the best thing to do here is nothing.
>

I think that’s fine.

Actually I see the other problem with pgindent, where if a “else” clause contains a multiple-line comment and a single statement without braces, for example:

```
else
/*
* comment
*/
printf(…);
```

Then pgindent will blindly add an empty line after “else”, so we get:
```
else

/*
* comment
*/
printf(…);

```

I tried to fix but failed. For that problem, a solution is to add braces to the “else” clause.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-12-02 22:51:15 Re: pgindent versus struct members and typedefs
Previous Message Nathan Bossart 2025-12-02 22:41:59 Re: use LW_SHARED in dsa_get_total_size()