Re: Removing useless #include's.

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> At Thu, 15 Feb 2018 11:12:05 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <6748(dot)1518711125(at)sss(dot)pgh(dot)pa(dot)us>
>> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>>> I found 641 includes that is just removable with no side effect
>>> with two exceptions.

>> I tend to be a bit suspicious of this sort of thing, especially for
>> old files that have been through previous rounds of "unnecessary
>> include" removal.

> As another point of view, placing an #include just because the
> source file uses the definition in the file is also
> reasonable. Header files are kept not to have a problem when
> included multiple times. I don't surprise if someone says that
> this is rather harmful. And I'm glas to read the clear reason.

Note that I'm *not* saying there's nothing to be done here. Scanning
through your patch quickly, the #include "postgres.h" in knapsack.h
is clearly contrary to project policy, and there should surely be
no need for any backend .c file to #include elog.h or palloc.h
because postgres.h pulls in both of those. But I'd like to see a bit
more analysis of most of the rest of these changes. The bad experience
we had with the last round of #include-removal was really because some
poor decisions had been taken before that about which headers should
include which other headers. I think it'd be a good idea to work backward
and see whether any of these proposed changes are pointing to header
inclusions that maybe weren't well thought out.

regards, tom lane