On Wed, Oct 15, 2025 at 1:44 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
>
> 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.
>
ok.
The attached patch only replaces relation_open to table_open.
RangeVarCallbackForPolicy already checks that a policy can only be created on a
table or a partitioned table.
so the replacement should be ok.
