Re: remove unnecessary include in src/backend/commands/policy.c
От | Álvaro Herrera |
---|---|
Тема | Re: remove unnecessary include in src/backend/commands/policy.c |
Дата | |
Msg-id | 202510120822.opybjj5dv345@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: remove unnecessary include in src/backend/commands/policy.c (Shinya Kato <shinya11.kato@gmail.com>) |
Ответы |
Re: remove unnecessary include in src/backend/commands/policy.c
|
Список | pgsql-hackers |
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. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Doing what he did amounts to sticking his fingers under the hood of the implementation; if he gets his fingers burnt, it's his problem." (Tom Lane)
В списке pgsql-hackers по дате отправления: