Re: Ordering of header file inclusion
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
vignesh C <vignesh21@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-10-20T04:53:57Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make the order of the header file includes consistent.
- e0487223ecac 13.0 landed
-
Make the order of the header file includes consistent in backend modules.
- 14aec0350230 13.0 landed
-
Make the order of the header file includes consistent in non-backend modules.
- dddf4cdc3300 13.0 landed
-
Make the order of the header file includes consistent in contrib modules.
- 7e735035f208 13.0 landed
Andres Freund <andres@anarazel.de> writes: > On 2019-10-19 21:50:03 +0200, Peter Eisentraut wrote: >> This class of change I don't like. >> The existing arrangement keeps "other" header files separate from the >> header file of the module itself. It seems useful to keep that separate. > If we were to do so, we ought to put bloom.h first and clearly seperated > out, not last, as the former makes the bug of the the header not being > standalone more obvious. We have headerscheck and cpluspluscheck to catch that problem, so I don't think that it needs to be a reason not to rationalize header inclusion order. I don't have a very strong opinion on whether modules outside the core backend should separate their own headers from core-system headers. I think there's some argument for that, but it's not something we've done consistently. And, as you say, there's no convention as to where we'd include local headers if we do separate them. regards, tom lane