Re: remove unnecessary include in src/backend/commands/policy.c - Mailing list pgsql-hackers

From Shinya Kato
Subject Re: remove unnecessary include in src/backend/commands/policy.c
Date
Msg-id CAOzEurRgM_JyYqOxEfBU6t6y7YNT6fzGvM9BvN8=jtiZOJ+iYA@mail.gmail.com
Whole thread Raw
In response to Re: remove unnecessary include in src/backend/commands/policy.c  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
On Sun, Oct 12, 2025 at 5:31 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> On 2025-Sep-30, Shinya Kato wrote:
>
> > However, the changes make policy.c rely on transitive includes. For
> > example, policy.c uses GETSTRUCT(), which is defined in
> > access/htup_details.h. Instead of being included directly, that header
> > is currently pulled in via a fairly long chain:
> > catalog/indexing.h -> nodes/execnodes.h -> access/tupconvert.h ->
> > executor/tuptable.h -> access/htup_details.h
> >
> > While this works for now, the dependency is fragile and could break if
> > header files are rearranged in the future. I'm not sure this is a good
> > practice, and although I couldn't find a specific rule against it in
> > PostgreSQL's coding conventions, it seems risky.
>
> Yeah -- I'm not very worried about the fragility being introduced, since
> if such a problem ever occurs it's very obvious and easy to fix.
> However, removing these include lines is just churn with no benefit,
> because those includes are still being processed via the indirect
> pathways.  We haven't saved anything.
>
> Just look at all the crossed wires here
> https://doxygen.postgresql.org/policy_8c.html
> Clearly the cross-inclusion of headers in headers is a mess.  Fixing
> that mess is going to cause *more* explicit inclusion of headers in .c
> files.  Removing a few explicit ones so that they become implicit, only
> to have to resurrect the explicit inclusion when we remove some of that
> cross-header inclusion is pointless.

Thank you, I agree with Álvaro. So, I think it is better to leave them
as they are, except for access/relation.h. And, replacing
relation_open to table_open looks good to me.

--
Best regards,
Shinya Kato
NTT OSS Center



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: get rid of RM_HEAP2_ID
Next
From: shveta malik
Date:
Subject: Re: Logical Replication of sequences