Обсуждение: typedef indentation in pg_shmem.h

Hi Heikki, Thomas,

The typedefs PGShmemType and HugePagesType are not indented properly.
That's because those entries are missing from typedefs list. Is that
intentional? Here's tiny patch fixing the indentation and typedefs
list.

-- 
Best Wishes,
Ashutosh Bapat

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
> The typedefs PGShmemType and HugePagesType are not indented properly.
> That's because those entries are missing from typedefs list. Is that
> intentional?

The reason this happens is that the automatic process for collecting
typedefs in the buildfarm only picks up typedef names that are used
to declare objects (variables, struct fields, function parameters or
results).

AFAICS neither of these typedef names are referenced at all, anywhere.

> Here's tiny patch fixing the indentation and typedefs
> list.

I don't think this is helpful, because that change will just get
undone the next time we absorb the buildfarm's list.  (And to be
clear, I consider the buildfarm's list to be the canonical one.)

I think the right way is to remove the unused typedefs, that is
along the lines of

-typedef enum
+enum HugePagesType
 {
...
-}            HugePagesType;
+};

We can put them back when/if there's a reason to use them.

            regards, tom lane

Hi Tom,

On Mon, Jan 12, 2026 at 8:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
> > The typedefs PGShmemType and HugePagesType are not indented properly.
> > That's because those entries are missing from typedefs list. Is that
> > intentional?
>
> The reason this happens is that the automatic process for collecting
> typedefs in the buildfarm only picks up typedef names that are used
> to declare objects (variables, struct fields, function parameters or
> results).
>
> AFAICS neither of these typedef names are referenced at all, anywhere.
>
> > Here's tiny patch fixing the indentation and typedefs
> > list.
>
> I don't think this is helpful, because that change will just get
> undone the next time we absorb the buildfarm's list.  (And to be
> clear, I consider the buildfarm's list to be the canonical one.)
>
> I think the right way is to remove the unused typedefs, that is
> along the lines of
>
> -typedef enum
> +enum HugePagesType
>  {
> ...
> -}                      HugePagesType;
> +};
>
> We can put them back when/if there's a reason to use them.

Thanks for your corrections. Your idea works, the changes survive
pgindent run. PFA patch.

--
Best Wishes,
Ashutosh Bapat

> The typedefs PGShmemType and HugePagesType are not indented properly.
> That's because those entries are missing from typedefs list. Is that
> intentional? Here's tiny patch fixing the indentation and typedefs
> list.

Hi all,

I just came across this email and wanted to chime in: it appears that a number of types in the kernel have in fact been
omittedfrom the typedefs.list, and it’s likely they were overlooked. For example:
 
```
BTParallelScanDescData
AfterTriggerEventDataNoOids
AfterTriggerEventDataOneCtid
AfterTriggerEventDataZeroCtids
PartitionDispatchData
MergeJoinClauseData
BufferAccessStrategyData
lwlock_stats_key
lwlock_stats
SerialControlData
AllocBlockData
```
I’m wondering if it’s worth addressing these.

--
Regards,
Man Zeng
www.openhalo.org

"=?gb18030?B?emVuZ21hbg==?=" <zengman@halodbtech.com> writes:
> I just came across this email and wanted to chime in: it appears that a number of types in the kernel have in fact
beenomitted from the typedefs.list, and it¡¯s likely they were overlooked. For example: 
> BTParallelScanDescData
> AfterTriggerEventDataNoOids
> AfterTriggerEventDataOneCtid
> AfterTriggerEventDataZeroCtids
> PartitionDispatchData
> MergeJoinClauseData
> BufferAccessStrategyData
> lwlock_stats_key
> lwlock_stats
> SerialControlData
> AllocBlockData

Did you read my reply?

            regards, tom lane

> Did you read my reply?
Hi Tom, 

Oh wow, I’ve re-read your previous message carefully, and I realize I overlooked or misunderstood it earlier. 
Sorry for the interruption.

--
Regards,
Man Zeng
www.openhalo.org