Hello,
On 2026-Feb-16, Andres Freund wrote:
> On 2026-02-16 17:18:36 +0100, Alvaro Herrera wrote:
> > I don't think the removal of pg_list.h works terribly well though, as
> > that is something that I would expect to be pretty much everywhere, so
> > it seems somewhat pointless to try to avoid it in this file.
>
> Yea, I was on the fence about that one.
>
> It does seem pretty crappy that pg_list.h is so widely included and in turn
> includes nodes/nodes.h, which then depends on the generated nodetags.h. For
> one it forces an unnecessary rebuild of too much if you add a new node type,
> but it also just aesthetically feels wrong.
Yeah, I was unhappy about pg_list.h too on my recent header hacking, and
perhaps we can improve this somehow, but I think it's a bigger effort.
> > I think we should in addition remove some includes that were kept during
> > recent IWYU hacking "for backwards compatibility", and instead include
> > them explicitly wherever they are needed. The attached does that.
>
> FWIW, the "for backwards compatibility" includes are from prep work towards
> shared memory stats. Before that all the stuff in backend_status.h,
> backend_progress.h and wait_event.h was in pgstat.h, which was quite
> unwieldy.
Ah, okay.
> The creation of those headers would have broken a lot of extensions if
> we had not provided those backward compat includes from pgstat.h.
Right ... TBH the real issue for me is that wait_event.h includes the
generated file wait_event_types.h (same complaint you had above), but I
decided that if I was wielding a weapon against pgstat.h, it could as
well be a shotgun. I guess I would be satisfied if we remove
wait_events.h from pgstat.h, and that probably won't break as many
extensions and won't have as much of a fallout. Although TB further H,
I don't really see it as terribly bad if we break extensions with this
kind of work, since the fix on their side is fairly easy, noninvasive,
and doesn't have to be done with any urgency.
> FWIW, your patch that you sent subsequently doesn't seem to apply cleanly for
> me? I think it's perhaps based on an older tree, it doesn't know about the
> conflict.h include yet... And it fails to build e.g. due to miscadmin.h
> defines around BackendType not being indirectly included in pgstat.h anymore,
> but there are many other failures...
Yeah, I just wrote it on (almost) clean master, but feel free to push
your changes whenever, and I'll rebase on top of that. I suspect the
failures just mean that the implicit header inclusions are worse than
they appear at first.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
