Re: Ordering of header file inclusion

vignesh C <vignesh21@gmail.com>

From: vignesh C <vignesh21@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-10-20T17:32:31Z
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 →
  1. Make the order of the header file includes consistent.

  2. Make the order of the header file includes consistent in backend modules.

  3. Make the order of the header file includes consistent in non-backend modules.

  4. Make the order of the header file includes consistent in contrib modules.

On Sun, Oct 20, 2019 at 2:44 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2019-10-19 21:50:03 +0200, Peter Eisentraut wrote:
> > diff --git a/contrib/bloom/blcost.c b/contrib/bloom/blcost.c
> > index f9fe57f..6224735 100644
> > --- a/contrib/bloom/blcost.c
> > +++ b/contrib/bloom/blcost.c
> > @@ -12,10 +12,10 @@
> >   */
> >  #include "postgres.h"
> >
> > +#include "bloom.h"
> >  #include "fmgr.h"
> >  #include "utils/selfuncs.h"
> >
> > -#include "bloom.h"
> >
> >  /*
> >   * Estimate cost of bloom index scan.
> >
> > 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.
>
> I'm -1 on having a policy of putting the headers separate though, I feel
> that's too much work, and there's too many cases where it's not that
> clear which header that should be.
>
Thanks Andres for reviewing the changes, I have modified the changes
based on your suggestions.
I have included the module header file in the beginning.
The changes are attached in the previous mail.

Please let me know your suggestions for any changes.

Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com