Re: remove unnecessary include in src/backend/commands/policy.c
От | Shinya Kato |
---|---|
Тема | Re: remove unnecessary include in src/backend/commands/policy.c |
Дата | |
Msg-id | CAOzEurRgM_JyYqOxEfBU6t6y7YNT6fzGvM9BvN8=jtiZOJ+iYA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: remove unnecessary include in src/backend/commands/policy.c (Álvaro Herrera <alvherre@kurilemu.de>) |
Список | 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 по дате отправления: