From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why does pgindent's README say to download typedefs.list from the buildfarm? |
Date: | 2024-05-16 14:45:18 |
Message-ID: | 2096381.1715870718@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> In these cases, I think for
> NotificationHash
> ResourceOwnerData
> WalSyncMethod
> we can just get rid of the typedef.
I have no objection to dealing with NotificationHash as you have here.
> ReadBuffersFlags shouldn't be an enum at all, because its values are
> used as flag bits.
Yeah, that was bothering me too, but I went for the minimum delta.
I did think that a couple of integer macros would be a better idea,
so +1 for what you did here.
> WaitEventExtension, I'm not sure, it's like, an extensible enum? I
> guess let's remove the typedef there, too.
I am also quite confused by that. It seems to be kind of an enum
that is supposed to be extended at runtime, meaning that neither
of the existing enum member values ought to be used as such, although
either autoprewarm.c didn't get the memo or I misunderstand the
intended usage. NUM_BUILTIN_WAIT_EVENT_EXTENSION is possibly the
most bizarre idea I've ever seen: what would a "built-in extension"
event be exactly? I think the enum should be nuked altogether, but
it's a bit late to be redesigning that for v17 perhaps.
> Attached is a variant patch.
I'm good with this, with a mental note to look again at
WaitEventExtension later.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-05-16 14:46:56 | Re: CREATE DATABASE with filesystem cloning |
Previous Message | Alvaro Herrera | 2024-05-16 14:30:22 | Re: AIX support |