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

From Peter Eisentraut
Subject Re: Why does pgindent's README say to download typedefs.list from the buildfarm?
Date
Msg-id 195c6c45-abce-4331-be6a-e87724e1d060@eisentraut.org
Whole thread Raw
In response to Re: Why does pgindent's README say to download typedefs.list from the buildfarm?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why does pgindent's README say to download typedefs.list from the buildfarm?
List pgsql-hackers
On 16.05.24 01:32, Tom Lane wrote:
> As for the remainder, they aren't showing up because no variable
> or field is declared using them, which means no debug symbol
> table entry is made for them.  This means we could just drop those
> typedefs and be little the worse off notationally.  I experimented
> with a patch for that, as attached.  (In the case of NotificationHash,
> I thought it better to arrange for there to be a suitable variable;
> but it could certainly be done the other way too.)  Is this too anal?

I agree we should get rid of these.

Over the last release cycle, I've been leaning a bit more toward not 
typdef'ing enums and structs that are only in local use, in part because 
of the implied need to keep the typedefs list up to date.

In these cases, I think for

NotificationHash
ResourceOwnerData
WalSyncMethod

we can just get rid of the typedef.

ReadBuffersFlags shouldn't be an enum at all, because its values are 
used as flag bits.

WaitEventExtension, I'm not sure, it's like, an extensible enum?  I 
guess let's remove the typedef there, too.

Attached is a variant patch.

Attachment

pgsql-hackers by date:

Previous
From: Quan Zongliang
Date:
Subject: Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block
Next
From: Peter Eisentraut
Date:
Subject: Re: An improved README experience for PostgreSQL